4 ms·

The CA system for TLS certificates is really dumb. Why can't we just upload a certificate chain as a TXT field in some DNS entry? Anyway, without HSTS, if your

by Eikon 5y ago

The CA system for TLS certificates is really dumb. Why can't we just upload a certificate chain as a TXT field in some DNS entry? Anyway, without HSTS, if your resolver is lying you are in bad waters and most (all?) CAs allow validation through dns records already. I'd much much prefer that as it would not be more insecure than "trusting" hundreds of third parties but would bypass a ton of useless organisations.

tptacek 5y ago
The obvious problem with storing certificate chains in TXT records is that it deeds control over your site cryptography to the government that controls your TLD, and, likely, to the "Five Eyes" IC consortium that probably exerts de facto control over the DNS roots themselves. We don't have to wonder whether governments manipulate the DNS for policy reasons; they do so loudly and proudly. People assume governments can simply suborn CAs directly, but that leads us to our next issue: A slightly less obvious problem with storing certificate chains in the DNS is that you can't revoke the DNS. You can, in fact, revoke entire chunks of the WebPKI. Not only have Chrome and Mozilla done so before, they did it to the largest and most famous CA. Google cannot revoke .COM; in fact, in practical terms, they can't even leave .COM, because hundreds of millions of users are trained to reach them at .COM. An even less obvious problem with storing certificate chains in the DNS is that virtually no software --- especially not the low-level library code that everything is built on --- is designed to assume that the DNS can fail for policy reasons. When certificates are for whatever reason rejected, you get a UI flow telling you what's going on. It doesn't do a very good job, but it's better than nothing, which is what you get with DNSSEC: your site silently falling off the Internet, as if it had never existed. There are other reasons too, but these are some of the high-level ones.
theamk 5y ago
This depends on your threat model. Here is mine, in order of importance: 1. Compromised local network (such as bad public wifi, tampering by ISP) 2. Compromised registrar (DNS or CA) 3. Compromised backbone internet (possibly because of state-level interference) 4. Compromised infrastructure of the website I am visiting ("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter) So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security. Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved. Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone. In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.
- tptacek 5y ago
  DNSSEC absolutely does not solve #1. Between you and your local resolver, DNSSEC collapses down to a single header bit, and while we have made large strides in signature cryptography, we have not yet secured single-bit signatures. Your ISP can trick you simply by flipping the "authenticated data" bit off or on in DNS headers. Problem #1 is why DoH exists. DoH does a good job at dealing with untrusted local DNS! In fact: it addresses most of the real on-the-wire threats to DNS, full stop. But it has nothing to do with DNSSEC.
toast0 5y ago
I agree that CAs are pretty dumb, but the certificate transparency logs are pretty nice to have. If a certificate must be logged to be used and if the logs are publicly accessible, I have a chance of noticing if someone got a certificate issued for my domain (either by tricking a CA, a nefarious CA, or by compromising DNS). I don't think I have a chance of noticing if certificates are just TXT records and someone can compromise DNS (especially if it's selective). Maybe if you also require DANE certificates to have certificate transparency records, but automation of ACME is probably simpler than automation of DNS changes.

by Eikon 5y ago

tptacek 5y ago

The obvious problem with storing certificate chains in TXT records is that it deeds control over your site cryptography to the government that controls your TLD, and, likely, to the "Five Eyes" IC consortium that probably exerts de facto control over the DNS roots themselves. We don't have to wonder whether governments manipulate the DNS for policy reasons; they do so loudly and proudly. People assume governments can simply suborn CAs directly, but that leads us to our next issue: A slightly less obvious problem with storing certificate chains in the DNS is that you can't revoke the DNS. You can, in fact, revoke entire chunks of the WebPKI. Not only have Chrome and Mozilla done so before, they did it to the largest and most famous CA. Google cannot revoke .COM; in fact, in practical terms, they can't even leave .COM, because hundreds of millions of users are trained to reach them at .COM. An even less obvious problem with storing certificate chains in the DNS is that virtually no software --- especially not the low-level library code that everything is built on --- is designed to assume that the DNS can fail for policy reasons. When certificates are for whatever reason rejected, you get a UI flow telling you what's going on. It doesn't do a very good job, but it's better than nothing, which is what you get with DNSSEC: your site silently falling off the Internet, as if it had never existed. There are other reasons too, but these are some of the high-level ones.

theamk 5y ago

This depends on your threat model. Here is mine, in order of importance: 1. Compromised local network (such as bad public wifi, tampering by ISP) 2. Compromised registrar (DNS or CA) 3. Compromised backbone internet (possibly because of state-level interference) 4. Compromised infrastructure of the website I am visiting ("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter) So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security. Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved. Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone. In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.

tptacek 5y ago
DNSSEC absolutely does not solve #1. Between you and your local resolver, DNSSEC collapses down to a single header bit, and while we have made large strides in signature cryptography, we have not yet secured single-bit signatures. Your ISP can trick you simply by flipping the "authenticated data" bit off or on in DNS headers. Problem #1 is why DoH exists. DoH does a good job at dealing with untrusted local DNS! In fact: it addresses most of the real on-the-wire threats to DNS, full stop. But it has nothing to do with DNSSEC.

toast0 5y ago

I agree that CAs are pretty dumb, but the certificate transparency logs are pretty nice to have. If a certificate must be logged to be used and if the logs are publicly accessible, I have a chance of noticing if someone got a certificate issued for my domain (either by tricking a CA, a nefarious CA, or by compromising DNS). I don't think I have a chance of noticing if certificates are just TXT records and someone can compromise DNS (especially if it's selective). Maybe if you also require DANE certificates to have certificate transparency records, but automation of ACME is probably simpler than automation of DNS changes.