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. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
