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
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
