Attackers control connectivity. Connectivity is expensive. Connectivity is also unreliable: captive portals, proxies, and firewalls break it. These factors make OCSP certificate revocation unworkable. For similar reasons, they make DANE's ostensible safeguard against malicious CAs unworkable. In practice, DANE would probably only be usable as an additional CA; it would not be able to effectively overrule any of the 1482 existing CAs.
The fact that TXT records don't work for some people shouldn't stop us. Anything that isn't currently widely used is broken for lots of people, because that's how networks are administered. Once it gets deployed and people start complaining, any specific network problem will get fixed.
Delaying proper network security because it won't currently work for a few percent of people seems like a recipe for never getting there.
It's a cost-benefit issue. Do you believe DNSSEC is so valuable that it's worth (a) breaking connectivity for a significant number of people and (b) incurring the expense of replacing/upgrading the middleboxes that are breaking connectivity? If so, why?
I'm reading these blogged opinions on DNSSEC and DANE and I notice that they never state the problem(s) that these "solutions" are meant to address. At least not explicitly.
Somehow I doubt it, but if by chance there is only one true problem being addressed and that problem is simply how do we authenticate another computer as being who we believe her to be, then my second question is: what is wrong with SSH authentication?
You need some secure, out-of-band, communication means to transfer the key fingerprint to be able to verify it. The whole aim of the CA structure is so I don't need to somehow find a secure means to contact Amazon to verify their key fingerprint prior to first connecting to their website.
[+] [-] tptacek|11 years ago|reply
Attackers control connectivity. Connectivity is expensive. Connectivity is also unreliable: captive portals, proxies, and firewalls break it. These factors make OCSP certificate revocation unworkable. For similar reasons, they make DANE's ostensible safeguard against malicious CAs unworkable. In practice, DANE would probably only be usable as an additional CA; it would not be able to effectively overrule any of the 1482 existing CAs.
[+] [-] Nimi|11 years ago|reply
[+] [-] tlb|11 years ago|reply
Delaying proper network security because it won't currently work for a few percent of people seems like a recipe for never getting there.
[+] [-] tptacek|11 years ago|reply
[+] [-] 101914|11 years ago|reply
Somehow I doubt it, but if by chance there is only one true problem being addressed and that problem is simply how do we authenticate another computer as being who we believe her to be, then my second question is: what is wrong with SSH authentication?
[+] [-] gsnedders|11 years ago|reply
You need some secure, out-of-band, communication means to transfer the key fingerprint to be able to verify it. The whole aim of the CA structure is so I don't need to somehow find a secure means to contact Amazon to verify their key fingerprint prior to first connecting to their website.
[+] [-] tptacek|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] tobias2014|11 years ago|reply
[+] [-] sarciszewski|11 years ago|reply
[+] [-] msturgill|11 years ago|reply
However, it is important to note that DNSSEC and DANE are two different things. Much of the recent discussion here has lumped them together.