Subject: [dns-privacy] Another TLS vulnerabilty, do we really want to bake DTLS into DNS?

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Oct 2014 12:04:58 -0400

http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/

TLS has been around 20 years now. It works really well for what it is
designed to do considering that the attack model is insane. I don't
know of any other crypto application where the attacker has the
ability to put a Turing machine in the tunnel to attack that
particular session.

TLS is also rather complicated. It has grown through a process of
incremental extensions. Client auth and restart were afterthoughts,
not integrated into the base design.

Implementations are of variable quality. Apart from Microsoft and
Peter's code, I am not aware of a TLS library that is adequately
documented. The OpenSSL implementation guide is a couple of blog
articles EKR wrote ten years ago. nssapi does not have sufficient
documentation to build it.

TLS has a 1990s approach to algorithm agility. Which is anything goes.
DNSCurve has a fixation with one curve. Neither realizes the
contemporary crypto approach is exactly one mandatory to implement
algorithm, exactly one backup algorithm and a mechanism that allows
for use of custom crypto if people really must.

So when people are suggesting that leveraging TLS is the easy path
because it is well understood, I get rather nervous. We understand the
use of TLS for its intended application and we are very good at
adapting 1990s technology to that application. That does not mean that
we are any good at adapting TLS outside the field of use that we have
experience of. And in fact that is where we have had problems in the
past - Heartbleed, restart, etc.

Part of my concern here is that DNS is used in a very different way to
TLS. Some deploy and forget devices use TLS, a few provide a server.
Every device uses the DNS. And the DNS is used to download updates.

Yes, I am using TLS inside PRIVATE-DNS. But the way I use it is
deliberately constrained so that even if there is a problem in TLS the
exploit window is limited to the initial connection. And for deploy
and forget devices it would probably make sense to specify a new
stripped down key exchange as an alternative to using TLS.