3 ms·

Why did DNSSEC/DANE not kill CAs? Are browsers being paid by CAs to bundle their root certificates?

by junaru 1y ago

thegagne 1y ago
Efficiency and ease of adoption would be my guess. The APNIC Ping podcast did an excellent 2 part series on the problems of DNSSEC. It puts more responsibility on the DNS systems that are already complex and doing a lot of work. The CA system with root trusts is just super efficient and easy, so it won. It’s not perfect, so I’m sure someday it will be replaced, but not by the current options.
- tptacek 1y ago
  Based on this Geoff Huston post: https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
tptacek 1y ago
Nobody is being paid by CAs. CAs and browser root programs are basically natural enemies. Three big problems faced browsers that tried to roll out DANE: 1. DNSSEC adoption on high-traffic/"important" domains is stubbornly very low (this used to be harder to quantify, but there's the Tranco list now; you can just take the top N of it and loop `dig ds` over it to get a %). 2. Middleboxes hassle DNSSEC queries, not everywhere but enough that the browsers need a fallback for browsers on network paths that won't transact DNSSEC, and once you have that fallback you have to account for an adversary who simply downgrades you to the fallback; this is the "you had 10,000 CA certificates, now you have 10,001" problem --- it's also the core of the drama behind the DANE "stapling" fiasco. 3. Browsers were able to get the WebPKI transparency ecosystem deployed using market levers they had over CAs, but they don't have the same leverage over DNS TLD administrators, so there's no "DNS transparency" on the agenda, nor could one plausibly be deployed. Similarly, you can revoke certificates (including CA certs) in ways you can't revoke DNS domains. It's kind of funny to look at short-duration certificates and ask "why didn't DANE save us from this", because a security engineer might look at this and think "thank God DANE failed an kept us from 30 more years of dangerous, error-prone manual key management".

Why did DNSSEC/DANE not kill CAs? Are browsers being paid by CAs to bundle their root certificates?

by junaru 1y ago

Why did DNSSEC/DANE not kill CAs? Are browsers being paid by CAs to bundle their root certificates?

Efficiency and ease of adoption would be my guess. The APNIC Ping podcast did an excellent 2 part series on the problems of DNSSEC. It puts more responsibility on the DNS systems that are already complex and doing a lot of work. The CA system with root trusts is just super efficient and easy, so it won. It’s not perfect, so I’m sure someday it will be replaced, but not by the current options.

tptacek 1y ago
Based on this Geoff Huston post: https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/

tptacek 1y ago

Nobody is being paid by CAs. CAs and browser root programs are basically natural enemies. Three big problems faced browsers that tried to roll out DANE: 1. DNSSEC adoption on high-traffic/"important" domains is stubbornly very low (this used to be harder to quantify, but there's the Tranco list now; you can just take the top N of it and loop `dig ds` over it to get a %). 2. Middleboxes hassle DNSSEC queries, not everywhere but enough that the browsers need a fallback for browsers on network paths that won't transact DNSSEC, and once you have that fallback you have to account for an adversary who simply downgrades you to the fallback; this is the "you had 10,000 CA certificates, now you have 10,001" problem --- it's also the core of the drama behind the DANE "stapling" fiasco. 3. Browsers were able to get the WebPKI transparency ecosystem deployed using market levers they had over CAs, but they don't have the same leverage over DNS TLD administrators, so there's no "DNS transparency" on the agenda, nor could one plausibly be deployed. Similarly, you can revoke certificates (including CA certs) in ways you can't revoke DNS domains. It's kind of funny to look at short-duration certificates and ask "why didn't DANE save us from this", because a security engineer might look at this and think "thank God DANE failed an kept us from 30 more years of dangerous, error-prone manual key management".