4 ms·
It's still an improvement over the way things where before (nothing at all, and complete blind faith in every part of the DNS and internet routing) and arguably
by swiley 9y ago
It's still an improvement over the way things where before (nothing at all, and complete blind faith in every part of the DNS and internet routing) and arguably better than CA which isn't that useful for email.
Furthermore, the browsers replace the TLD in who you trust with CAs and in many cases it's practically difficult (or impossible) to "fire" your browser.
I will agree that no one seems to use good crypto with DNSSEC though. The only people I know using it are using 512 bit RSA which is pretty horrifying.
- gruez 9y ago>it's practically difficult (or impossible) to "fire" your browser. You can reconfigure your trust store, and you can distrust a CA in a few clicks.
- tptacek 9y agoNot only that, but Firefox and Chrome have "fired" some of the largest, "most important" CAs on the Internet. We know there's no TBTF problem with the Web PKI. But there is literally no way to fire a DNS TLD operator. In this scheme, they are prêt-à-porter TBTF.
- Nullabillity 9y ago> We know there's no TBTF problem with the Web PKI. Hardly. Comodo is still around, and Symantec took years to be gradually distrusted. Hell, even the WoSign/StartSSL debacle started in Jan 2015, and they weren't removed before Jan 2017.
- jcranmer 9y agoThe WoSign issues became public around early September 2016 (maybe last week of August): https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&action=history https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&ac...
- gruez 9y agonot to mention that wosign came out in early 2015. https://news.ycombinator.com/item?id=8982013 https://news.ycombinator.com/item?id=8982013
- tptacek 9y agoThis is a rebuttal to some argument, but not mine.
- rphlx 9y agoIn many cases (such as Let's Encrypt) the CA verification process is merely "controls some DNS resource" or "controls some HTTP response that directly depends on DNS". In that case it is theoretically impossible for the cert to be more trustworthy than DNS(SEC). [The cert's untrustworthiness is DNS's untrustworthiness plus the CA's untrustworthiness plus some other misc factors, such as TLS library untrustworthiness].
- ietf-dane 9y agoSurvey says: 5.2 million DNSSEC domains, and ~12,000 with 512-bit RSA keys concentrated at just two small DNS providers. So good job knowing only the few stuck with early 90's export crypto. :-) They'll be shamed into fixing this soon enough. An even larger provider that had 512-bit RSA keys no longer does. And even a 512-bit RSA key is slightly better than nothing. One needs to remember that DANE in SMTP is a mechanism for downgrade-resistant transition from unauthenticated opportunistic STARTTLS to authenticated required STARTTLS. Below is the frequency table for RSA key lengths in zone signing keys (primarily 1024-bit RSA keys): count | bits ---------+------ 8402 | 4096 1135 | 3168 17 | 2432 103 | 2304 20 | 2088 5 | 2064 55927 | 2048 15 | 2024 315 | 1536 17 | 1352 43 | 1304 185095 | 1280 63 | 1152 74 | 1048 291 | 1032 4019966 | 1024 28 | 768 12545 | 512 The KSK (key-signing keys registered in parent DS RRs) RSA key size frequencies are (mostly and increasingly 2048-bit): count | bits ---------+------ 39715 | 4096 11 | 3248 1149 | 3168 47 | 3072 267 | 2560 25 | 2304 20 | 2088 3051386 | 2048 17 | 1552 180111 | 1536 171 | 1304 1568 | 1280 34 | 1152 1118500 | 1024 11806 | 512