New IAB Chair Defends DNSSEC

bednarz writes "Olaf Kolkman, the new chair of the Internet Architecture Board, says that DNSSEC — an approach to authenticating DNS traffic that has been slow to take off — is not a failure. 'It is taking a while to percolate into software, and for that software to percolate into the market, and for people to adapt their environments to deploy and operate DNSSEC. The deployment is hindered by a chicken-and-egg problem'."

If DNSSEC Is Success, What Does Failure Look Like?

[tqbf]

Nothing about DNSSEC has improved since wrote about it last year [matasano.com]:

• The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
• Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
• It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
• The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.

DNSSEC is a huge waste of time. For a fraction of the effort, we could have pervasive opportunistic VPN-style connections. Or we could clean up the mess of insecure code that currently provides our core infrastructure. Or a unified standard secure email transport based on GPG/PGP. Or a concerted effort to solve the cross-site scripting problem. You could come up with a way to secure and authenticate the AOL OSCAR IM protocol and still do more good than DNSSEC ever will.

Of course, the IETF people will never admit this. The IETF types used to define themselves by making fun of the OSI X-standards people; "rough consensus and working code!". The Internet won, CLNP lost. Where do you think all those standards bureaucrats you made fun of in the OSI groups went? That's right; to IETF working groups.

Re:DNSSEC doesn't seem very useful

[slamb]

But nobody (or not many people) use DNSSEC to encrypt zone transfers, and almost everybody hits a recursive nameserver run by your ISP or perhaps local to your company's network, which means that the end-user is never going to know whether the DNS query they issued returned a signed response or was forged from the authoritative DNS server.

DNSSEC doesn't encrypt anything, just authenticate. And it fits into the DNS design of caching and recursive nameservers - believe your ISP's server will give you something that proves the answer came from the authoritative server at some time less than $TTL seconds ago. Now, I don't remember if your ISP's nameserver has to have special DNSSEC support or not to pass that information to you...probably yes, which is another infrastructure hurdle.

Right now, you have to dig deep into the bowels of BIND to even notice whether a zone has been signed, and there is pretty much zero feedback about that status which propogates back to a client like a web browser or your platform-specific software update mechanism. Until that changes, I don't see DNSSEC doing anything really useful to solve the genuine problems which it might be useful to solve. If all you wanted was a way to encrypt zone transfers, using rsync over SSH is a lot easier to deal with.

I'd take advantage of DNSSEC if the infrastructure were there - including a public key in a DNSSEC-authenticated zone would be a good way to authenticate a host. There are two other ways in common use by the clients you mentioned, and neither is quite satisfactory:

• web browsers - they use PKI with trusted third-party roots to verify the site is who it claims to be. Disadvantage: you have to manage that list of trusted third parties, and typically the widely-trusted ones require cash to authenticate a server. Takes time to get the certificate, too.
• ssh - it doesn't validate the key initially, unless you do so manually. How many times have you seen this message, and how many times have you actually checked the fingerprint before typing "yes"?

  The authenticity of host 'foo' can't be established.
  RSA key fingerprint is ....
  Are you sure you want to continue connecting (yes/no)?

  subsequent connections from the same client are at least verified against your local known hosts. This would be an excellent candidate for retrofitting - the client could retrieve the key from DNSSEC if it's there, and present you with this message otherwise. Over time, people would become more suspicious on seeing it.

  In fact, I just googled for "ssh dnssec" and it looks like someone has already written the code for this.

New protocols could rely on DNSSEC instead, and there are probably other protocols like ssh that could be retrofitted easily.

I'm not holding my breath on the infrastructure, though. It's been a while since I've looked at DNSSEC, but IIRC most of the benefits don't come until it's deployed from the root on down. Until .org uses DNSSEC, I can't really use it for slamb.org. I could manually add slamb.org's key into my client software maybe, but that's really not much better than creating my own root certificate for existing PKI mechanisms.

Re:Personal motivation?

[rucs_hack]

You really want your 3- and 6-year olds to inherit the spam-ridden porn-fest we have today? That's just mean. Think of the children!

I don't get this porn fest thing. I use the interwebs all the time, and barely ever see any porn. Where is this porn of which you speak?

The core principle of the internet to me is that anyone can edit it/add to it, or take it in some new direction.

We have Wikipedia, 'Ask a Ninja' and Red vs Blue now. Three things I never would have thought of when I first plugged my 33k modem in, many years ago. My contribution to the web's main attribute is that people keep visiting my site and downloading because they think its a mod for Wow (confusion in the name). Then they discover its really boring...