Hacker News new | past | comments | ask | show | jobs | submit login

Just to be clear:

> DNSSEC/DANE replaces domain validated certificates.

DNSSEC/DANE can be used to replace CA-issued certs, but it can also be used to add an extra layer of validation to existing CA-issued certs. To me this is actually the strongest use-case for DANE, as it provides a means to use DNSSEC to ensure that you are using the correct TLS certificate.

More info is here:

http://www.internetsociety.org/deploy360/resources/dane/

The four modes are:

----

0 – CA specification – The TLSA record specifies the Certificate Authority (CA) who will provide TLS certificates for the domain. Essentially, you are able to say that your domain will ONLY use TLS certificates from a specific CA. If the browser or other application using DANE validation sees a TLS cert from another CA the app should reject that TLS cert as bogus.

1 – Specific TLS certificate – The TLSA record specifies the exact TLS certificate that should be used for the domain. Note that this TLS certificate must be one that is issued by a valid CA.

2 – Trust anchor assertion – The TLSA record specifies the “trust anchor” to be used for validating the TLS certificates for the domain. For example, if a company operated its own CA that was not in the list of CAs typically installed in client applications this usage of DANE could supply the certificate (or fingerprint) for their CA.

3 – Domain-issued certificate – The TLS record specifies the exact TLS certificate that should be used for the domain, BUT, in contrast to usage #1, the TLS certificate does not need to be signed by a valid CA. This allows for the use of self-signed certificates.

----

Modes 0 and 1 work with current CA-issued certs and assume that normal PKIX X.509 validation is occuring.




It can not be used this way. Adam Langley explained why. It has to do with the way browsers work. If there are 4,392 trusted CAs today, DNSSEC will make it 4,393. In practice, DNSSEC strictly makes the CA system worse.

People involved in DNS standardization clearly believe this isn't the case, and that there's a spectrum of different ways DNSSEC will interact with the CA system. They also believed in Interdomain IP Multicast and SNMPv3. The track record of DNS standards people on browser technology is not good. In this case: I suggest taking AGL's word for it.


Thomas, I definitely defer to AGL when it comes to browser technology - and I've certainly read his "Not DANE" piece, but you'll note he did not entirely rule it out. He just said it may be "a long way out". Two comments:

> It can not be used this way.

Actually, it can be. There's a modified version of Firefox maintained by the team at the DNSSEC-Tools project called "Bloodhound" that does DNSSEC validation of every link and does DANE checks on TLS certs:

http://www.dnssec-tools.org/bloodhound/bloodhound.html

> If there are 4,392 trusted CAs today, DNSSEC will make it 4,393.

Hmmm... I guess I see that only if you were using modes 2 and 3 of DANE. If you are using 0 and 1 you are just using DANE as an additional check for the CA-issued CERT.

The value to me is that I am in control of the TLSA record in that I am publishing that in my own zone file on my own DNS servers. I can specify there precisely which TLS cert I want to use or which CA I want to be trusted for my domain.

My choice is then cryptographically signed via DNSSEC and bound into the global chain of trust via DS records going back up to the root of DNS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: