Automatic e-mail encryption

[Doug Barton]

On 07/21/2014 09:23 AM, Peter Lebbing wrote:
> By the way, regarding DANE as an alternative to the CA system: I think a proper
> implementation of authentication through DNS could well be way better than the
> CA system: at least you can only be screwed by people having access to signing
> keys for the root and the TLD, instead of anyone with access to a CA certificate.

SSL/TLS is designed to (primarily) do two things, of roughly equivalent 
importance depending on the context:

1. Provide a framework to cryptographically secure the communication channel
2. Provide some level of assurance that the endpoint you've connected to 
is actually the entity you intended to communicate with

What DANE does is provide a DNS resource record which gives you the 
signature of the certificate that's relevant to the host name you want 
to connect to. The system assumes that both the host record and the DANE 
RR (TLSA) are signed with DNSSEC.

This facilitates purpose number 1 above as it allows the connection to 
start off encrypted. It also allows your client to verify that the 
certificate it gets is the one it was looking for. Assuming that you 
have the same level of confidence in the organization you're 
communicating with to manage their DNSSEC keys properly as you do for 
them to manage their SSL keys properly, it also fulfills purpose number 2.

As Peter points out however, you're simply transferring your trust in 
the hierarchy "above" the organization you're communicating with from 
the CAs to the TLD and root zone operators. The good news is that for 
now the TLDs have proven very trustworthy in their handling of their own 
DNSSEC keys, and replacing them due to a compromise is orders of 
magnitude easier than revoking/replacing CA signing certs. I will leave 
judgment of how the root zone operators are doing up to the reader, as 
my opinion would undoubtedly be biased. :)

hth,

Doug