
Ed25519 for DNSSEC - fanf2
https://ed25519.nl/
======
tptacek
This sounds interesting but really isn't.

Think about it for a second and you'll realize that _specifying_ a modern
signature scheme for DNSSEC is trivial. The best modern signature schemes are
designed to be easy to adopt!

The problem is that none of the installed DNSSEC base groks ed25519. It took
years to get P-curve DNSSEC --- which virtually nobody uses --- to the point
where its mere presence didn't break resolvers. It would probably take
something on the order of 10 years of concerted effort to get 95%+ of active
resolvers to grok ed25519, and during that time everyone who wanted secure
signatures would need to sign both with RSA and with ed25519, and for 10 years
_after that_ we'd be dealing with people keeping insecure RSA signatures
around out of compat concerns, and then comes the Usenix papers about
downgrade attacks, and at night the ice weasels come, just like anyone who's
dealt seriously with TLS will tell you.

What's especially irritating about this situation is that we _know_ the
signature scheme used in "mainstream" DNSSEC is inferior to modern curve
signatures, and we know virtually none of the DNSSEC software being deployed
can grok modern curve signatures, and we know this is an upgrade that needs to
happen lest we get a whole crapload of new 1990s crypto deployed across the
Internet, and still DNSSEC advocates are pushing for more deployment of this
stuff.

Nobody uses DNSSEC right now. If the root private keys were dumped to Pastebin
right now, to a pretty good first approximation not one commercial operator on
the Internet would need to send out a breach warning to customers. We should
all be taking a breath and reconsidering the protocol and its implementation
details.

This, of course, isn't all that's wrong with DNSSEC. Google [against dnssec].

~~~
colmmacc
Those are like hipster reasons to not like DNSSEC! DNSSEC is just dumb and
doesn't work.

    
    
      [ User ] <-----> [ Resolver ] <-----> [ Auth DNS ]
                  ^                    ^
      Most attacks work here     DNSSEC protects here

~~~
jopsen
Presumably advanced users can pick a resolver with DNSSEC support?

~~~
aaronmdjones
You mean the resolver does the verifying? That doesn't solve anything; anyone
doing an MITM attack between the user and their resolver can flip the 'ad'
(Authenticated Data) bit to '1' even if the verification failed, and if the
user isn't verifying the signatures too, they will blindly trust the value of
this bit.

Users need to run their own local /verifying/ resolvers for this to be secure
(or have a trusted path between them and their remote resolver, e.g. IPsec-AH
or DNScrypt).

------
bluejekyll
A little Self promotion: TRust-DNS Resolver and Client support ED25519.
Currently working through some issues on the signing logic in the Authority.

[https://github.com/bluejekyll/trust-dns](https://github.com/bluejekyll/trust-
dns)

~~~
ktta
Any interest in implementing DNSCrypt? I feel DNSSEC alone is useless since
one can't guarantee integrity to the DNS resolver.

~~~
bluejekyll
I looked at DNSCurve, I wasn’t really happy with the complexity of
implementing it. I got so far as understanding the protocol, even found a bug
in the docs. If someone else wanted to look at this, I’d gladly work with them
to implement it.

Personally, I’m much more interested in DNS over TLS, b/c I can leverage
existing (already have!) TLS implementations.

Edit: I’d also debate the usefulness of DNSSec without curve. Curve and and
DNS over TLS provide privacy with the Resolver/Authority, while DNSSec still
independently can verify the authenticity of the RRSET. It still provides a
good service in that context.

~~~
ktta
Sorry, I meant DNSCrypt (I thought I edited it soon enough). DNSCrypt is meant
to be more about the last leg encryption/integrity/authenticity guarantee
(compared to DNSCurve atleast) between a client and (caching) server.

I agree with you on the DNS over TLS part. It is definitely a great idea. With
TLS, secure transport implementations are already done to death so I guess we
don't have to worry about another. I do have a question though. How are you
handling the DNS request for the initial TLS connection? I'm talking about
this:

1\. Want to make DNS query for X.com

2\. Connect to personal-dns-server.com over TLS connection for DNS request.

3\. Want to make DNS query for personal-dns-server.com.

4\. ?

I'm asking this because your TLS implementation seems to be about the whole
works - including the CA system. Which needs a CN. Which needs to be resolved
(I initially thought it was just about the key neg + transport part of TLS
with a hardcoded IP address in the config file)

About DNSSEC + DNSCurve/TLS. I just wasn't talking about privacy. Integrity
was my primary concern. DNSSEC isn't widely deployed, so we don't really know
which domain implements DNSSEC and which doesn't. So in the last leg of DNS
reply, one can just remove the RRSIGs and make it look like DNSSEC was never
implemented. Pretty much a downgrade (to nothing) attack.

Also, we don't have any way of warning the user if a RRSIG doesn't validate
the A rec properly, so what's your plan on this? A while ago I had a similar
idea you did, but more geared towards being an on-disk cache (check out pdnsd
- sad it is unmaintained though) where I thought eventually it has to step
into user alerts using the notification daemon.

~~~
bluejekyll
Let me unpack this starting from here:

>I'm asking this because your TLS implementation seems to be about the whole
works - including the CA system. Which needs a CN.

Yes, I am leveraging the standard TLS design, it includes the defaults as
specified by the underlying TLS implementation; currently this is openssl,
native-tls, or rustls. Like DNSCrypt (Curve), the server must be registered
out-of-band if it is not signed by one of the CA's registered in the system. I
thought about this for a while, and decided it was best for ease of use to
rely on the system CAs and allow additionals to be registered.

> Which needs to be resolved (I initially thought it was just about the key
> neg + transport part of TLS with a hardcoded IP address in the config file)

This isn't accurate. The CN is only used by the underlying TLS library to
validate the Subjects in the X509 cert returned by the server. There is no
additional lookup required for that name. Honestly, since that name isn't
being used for resolution (i.e. your using IPs in DNS config), this doesn't
provide as much value in DNS as it does in standard TLS connections where a
name was resolved to an IP, but at least it would validate that the NS servers
are named what you expect.

> How are you handling the DNS request for the initial TLS connection? I'm
> talking about this:

>

> 1\. Want to make DNS query for X.com

> 2\. Connect to personal-dns-server.com over TLS connection for DNS request.

> 3\. Want to make DNS query for personal-dns-server.com.

> 4\. ?

Again, there is no "DNS" request for the TLS connection, this is the order:

1\. A direct IP connection to the remote TLS server based on configuration,

2\. The TLS handshake is performed with that server, using the associated CN
on the connection, and validating against the associated CA list

3\. Standard TCP DNS request is performed from this point.

Does that help clarify this impl?

~~~
ktta
Apologies. Your implementation was a little tricky to understand. Excellently
commented though.

Can you give me an example config file for the client? (I could only see one
for the server)

PS: In a couple places, 'Ellyptic' was written so you might want to correct
that.

~~~
bluejekyll
The Client/Resolver doesn't actually have a config for enabling TLS ATM, this
should be added as a backlog issue. At the moment you'd have to build this
into a custom Rust impl. I've been considering whether it can be an addition
to the resolv.conf, or should just have a separate TOML.

If you don't mind, would you want to file an issue and describe how you want
to use this?

Edit: I have been planning on a system daemon caching resolver that can be run
on any OS. This work is only just getting started.

> In a couple places, 'Ellyptic' was written

Yeah, me and spelling have had a issue going all the way back to 1st grade ;)

Edit: btw, you're comment about CN got me thinking again about the correct
usage of that, and I wonder if "name" is even correct. It might be better to
have the certs be validated against IP's listed in the Subject of the Cert...
I need to revisit this.

btw, here's a good example from one of the tests that shows how to set this
up: [https://github.com/bluejekyll/trust-
dns/blob/master/rustls/s...](https://github.com/bluejekyll/trust-
dns/blob/master/rustls/src/tests.rs#L193-L207)

~~~
ktta
Thanks. I'll check it out. What you are saying can work if the client has a an
IP/port and the CN that is in the Server's Cert in a config file. If you are
targeting linux I would say have a new config file in /etc . Messing with
resolv.conf isn't recommended since it is re-generated frequently.

------
Diederich
Interesting. From the web page:

"This domainname, is DNSSEC signed with this algorithm."

Yet:

dana@araman:~$ whois ed25519.nl

Domain name: ed25519.nl

Status: active

Registrar: TransIP BV Schipholweg 9b 2316XB LEIDEN Netherlands

Abuse Contact:

DNSSEC: no

Domain nameservers: mango.plexis.eu pdns-public-ns1.powerdns.com pdns-public-
ns2.powerdns.com

Record maintained by: NL Domain Registry

...

I'm inclined to believe the claims of the web site without checking. It's just
interesting that:

1\. The whois data for .nl is taking some interest in DNSSEC

2\. That they are wrong about it being DNSSEC signed.

My (weak) guess is that whatever they are using to get the DNSSEC information
doesn't understand Ed25519.

~~~
aeden
I've checked, it's definitely signed:

    
    
      ; <<>> DiG 9.11.0-P1 <<>> ed25519.nl +dnssec
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 594
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags: do; udp: 512
      ;; QUESTION SECTION:
      ;ed25519.nl.			IN	A
      
      ;; ANSWER SECTION:
      ed25519.nl.		1341	IN	RRSIG	A 15 2 3600 20171012000000 20170921000000 27662 ed25519.nl. Z62ywpWQ4ahOs0DZxIs3OAY67qc226z6rs8k8q2i/hdwQAjz5EL5ZJke t25LD88wx5kGY5ru6Dvfrd7KvODCAg==
      ed25519.nl.		1341	IN	A	77.72.150.82
    
      ;; Query time: 55 msec
      ;; SERVER: 8.8.8.8#53(8.8.8.8)
      ;; WHEN: Wed Sep 27 20:44:46 EDT 2017

~~~
teddyh
The zone may be signed locally, but the DS records for ed25519.nl haven’t
(when I checked myself just now) yet been exported into the TLD zone. It’s
basically equivalent to a self-signed certificate. The lack of DS records in
the TLD zone is the reason why WHOIS says "DNSSEC: no".

~~~
Habbie
The .nl registry does not support algo 15 (and 16) for DS records yet. Support
is expected soon.

------
vmp
I had to turn off DNSSEC support for my Bind9 at home, from time to time pages
wouldn't resolve or it would take up to 10 seconds (ages!). When I checked the
logs it was something about EDNS packet sizes that tripped it up. Turned EDNS
off (and DNSSEC with it) and had no issues what so ever. It's a pretty
standard installation with a few master zones and it's resolving queries
directly - without forwarding to ISP or GoogleDNS or anything.

