Ed25519 for DNSSEC | Hacker News Reader

Ed25519 for DNSSEC

ed25519.nl

58 pointsfanf235 comments

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].

Not that I disagree with anything you’ve written, but you’ve fallen into the “X sucks but I offer no alternative” trap.

What is your suggestion instead of DNSsec? DNScurve? No DNS security at all and rely on TLS and certificates? Other?

His suggestion is precisely that---do nothing. From https://news.ycombinator.com/item?id=8897347:

There is a real alternative solution, and it has the virtue of being exceptionally simple: do nothing. The DNS doesn't need to be secured, just like raw IP isn't, nor every individual BGP4 update.

That's a fair argument.

The obvious counter argument is that we need more layers of security.

Example: HTTPS + GPG signature gives you two layers, even if most skip one of them.

Adding more layers doesn't necessarily add security. Jokes about ROT13'ing twice, or the meet-in-the-middle attacks on Double-DES are well-known examples of it.

What would your security policy be if only one of the signatures matches and the other one fails? More importantly, if you're setting your policy to be tolerant of as-of-yet unspecified algorithms, you run the risk of the attacker being able to screw you over in the weak protocol and corrupt the bits of the strong protocol to an unknown protocol.

Even if the "something must be done! this is something!" school of security design was valid, DNSSEC would still be terrifying. The primary use case for DNSSEC is DANE, which replaces the Web PKI CA system with DNS zones. The DNS is a tree-structured PKI the tops of which are controlled explicitly and de jure by world governments, and, unlike the X.509 CAs, Google can't administer a death penalty to .COM.

This is critical. We should not be pushing technology that further bolsters the power of central authorities, especially in an age of increasing authoritarianism.

An important thing about layers, about defense in depth, is that you can’t even begin to attack one mechanism until you’ve defeated its predecessors. DANE + TLS doesn’t give you layers. If I can subvert your DNSSEC, I can endorse a fresh TLS key, and win. If I can subvert your TLS, I win.

This is defense in breadth, a strategy known mostly for its close association with defeat.

It depends on your use case. In the context of TLS this is true. In the context of wanting DNS to stand on it's own for use cases outside TLS, then having signed and validated data in DNS is valueable.

>nor every individual BGP4 update.

@tptacek, can you explain that? Without signing AS path changes with BGPSEC you get path-lengthening and path-shortening attacks which work just as well as subprefix hijacks.

BGP hijacking is still a massive problem and RPKI alone isn't close to enough to fix it.

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

Presumably advanced users can pick a resolver with DNSSEC support?

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).

Actually, that's not where most attacks work.

Most attacks rely on people thinking that google.com.please.dont.read.this.part.of.the.domain.evil.com is really google.com.

He meant most DNS attacks. DNSSEC does nothing about the *.domain.evil.com attack.

(throws caution to the wind...)

DNSSec is not dumb. The gap you're pointing out is valid for most standard user OS's that are not performing DNSSec validation and/or are not using private/secure/authenticated channels to their upstream resolver. DNSCrypt and DNS over TLS solve the later. But, there's no reason that users can't run validating Resolvers locally as well, thus filling in the gap you point out.

Now, most users and OS' out there don't provide these capabilities, so the gap you point out is 100% accurate based on the current state of the world. But, shouldn't we fix this and start bringing the validation to the end user OS'?

tptacek's criticism's are more on point, b/c they get to the heart of some issues in the deployment and actual security of the DNSSec network, and these are foundational issues that we need to resolve. I'm optimistic that we can solve them and I don't think we should give up just b/c it's non-ideal today.

"Nobody uses DNSSEC" illustrates the tragic failure of imagination among its main critics. This is the same thinking that causes venture capitalists to destroy loads of modestly successful businesses every year determined to have a one-in-a-million smash rather than make an honest living quietly succeeding.

DNSSEC works fine so long as the people doing the resolving have, or are given, a reason to actually care about the thing it delivers, ie security. Ordinary users are here to see the dancing pig, they aren't going to enable DNSSEC or switch off JavaScript, or use a password to lock their phone, but that doesn't make any of those things useless.

So, two actual applications, of DNSSEC being used today. One, SSHFP. Instead of TOFU with all the risks that implies, or the "fun" of pushing out current key lists to all users if we have DNSSEC we can use SSHFP to put those keys into DNS without anybody tampering with them.

Second CAA. Unlike most DNS records, CAA has deliberately small audience and we can mandate them to implement DNSSEC. Indeed if there was a compelling reason to do so we can mandate that they implement whatever new ECC schemes are making the usual suspects wet themselves this week. You can try this for yourself, set CAA issue to a commercial CA of your choice then try to order a free Let's Encrypt certificate. It says No. Without DNSSEC of course bad guys able to pass a validation can also forge the CAA answer. But with it their forgery is detected, we don't care whether my mother has a working resolver because my mother isn't a trusted CA.

I think you'll have a tough row to hoe to establish that I don't care about security.

More importantly, you haven't addressed the concern I just raised. Whether or not you want your SSH keys to be part of a global PKI whose tops are controlled by world governments, the push for deployment of RSA-only DNSSEC software today does in fact make it harder in the long run to deploy ed25519 DNSSEC.

Here are a bunch of arguments against DNSSEC, most of them rooted in security. Which do you find flawed, and why?

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

> I think you'll have a tough row to hoe to establish that I don't care about security.

Now I'm a little disappointed GP wasn't a bit more aggressive in their assertion and targeted it towards you, just so we could get something like cperciva's Putman comeback.[1] ;)

1: https://news.ycombinator.com/item?id=35079

Reading that and your FAQ for that post led to quite some amusing sites. My favorite so far is this: https://ianix.com/pub/dnssec-outages/20170914-dnssec-name-an...

Don't stop at proclaiming these to be merely "arguments against DNSSEC" call them what they are, arguments for nihilism. Everything is awful we should give up on the whole enterprise

Now, when JWZ does that it's funny because he had the courage of his convictions and now owns a nightclub instead. But if somebody tries to pretend this is a useful basis on which to actually make technical decisions they're having a laugh.

Meanwhile those of us who thought it possible to actually make things better rather than pouring scorn have been doing so. Rather than insisting that anything short of perfection is worthless garbage, we have been incrementally improving on the status quo so that the world you described in 2015 now seems distant.

On their own Ballot 169, the ACME protocol, expiry of the FPKI cross, RFC6962, the distrust of the last remaining grandfathered CAs, CAA, these are all small things. But assembled they amount to a situation in which the trust needed to make the Web PKI safe has shrunk considerably, and where DNSSEC (but not DANE) comes into its own.

> we can mandate them to implement DNSSEC

This is a common theme in DNSSEC -- its main deployment tools are force and financial incentivization. Well those two, and shameless disinformation like DNSSEC is encrypted (DNSSEC is NOT encrypted!), or that it prevents hackers from taking over your website (Godaddy tells its customers this).

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

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

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.

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.

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?

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.

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...

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.

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.

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

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".

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

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.

Reply on news.ycombinator.com