RFC 9498: The GNU Name System

Posted Nov 27, 2023 18:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: RFC 9498: The GNU Name System by NYKevin
Parent article: RFC 9498: The GNU Name System

> Well, that's a showstopper. Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."

That's not true. We have plenty of technologies that "sometimes" work, but being in a browser slowly pushes them to work everywhere. Example: WebRTC.

> Presumably, this is restrictive DANE. Your threat model is an attacker obtaining control of the certificate, and now you want to revoke it with DANE. It was previously a valid certificate issued by a CA (and not additive DANE).

No. The threat model is a hostile certificate issued by a government-controlled or a compromised CA. The attacker doesn't have access to my system. This is the main problem with the PKIs, any CA can issue a certificate for any domain.

DANE would require the attacker to not only compromise one CA somewhere, but to compromise my particular top-level domain registrar and my DNS provider.

So basically, you have the matrix:

1. A legacy CA certificate without stapled DANE. The browser will have to do a DNSSEC-secured query to verify that there is no DANE record for this domain name. A browser can cache the outcome ("no DANE record, verified via DNSSEC") for a reasonable time.

2. A CA certificate with "must staple" bit set and a stapled DNSSEC chain. The browser verifies them both, and everything works with zero overhead.

3. A CA certificate without "must staple", and an existing DANE record (that the adversary wasn't able to tamper with). This immediately means an attack.

4. A DANE record without a CA certificate, verified via a stapled DNSSEC chain. This is the optimal outcome.

RFC 9498: The GNU Name System

Posted Nov 30, 2023 0:47 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

> 1. A legacy CA certificate without stapled DANE. The browser will have to do a DNSSEC-secured query to verify that there is no DANE record for this domain name. A browser can cache the outcome ("no DANE record, verified via DNSSEC") for a reasonable time.

And *that* is why the stapling proposal fell apart. You can't hard-fail on that DNS query, because some ISPs will not serve it correctly and you would display a spurious warning. Such warnings do more harm in aggregate (by training users to ignore them) than the extremely limited number of MitM attacks you would realistically prevent.

RFC 9498: The GNU Name System

Posted Nov 30, 2023 8:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> You can't hard-fail on that DNS query

I mean, you can. And with DoH/DoT it's pretty easy to do the query to work around broken ISPs.

Browsers also have a "bully pulpit" they can start with just silently ignoring DNSKEY query failures, then a couple years later start showing a banner like "your ISP is tampering with your DNS", then put the DNSKEY-failed connections behind the usual scary "certificate might be invalid" dialog.

> Such warnings do more harm in aggregate (by training users to ignore them) than the extremely limited number of MitM attacks you would realistically prevent.

The same statement could be made about deprecating HTTP.

Especially since it has caused half of the Internet to depend on one _service_ (Let's Encrypt). Its failure will basically cause an Internet-wide blackout, all to prevent occasional malicious MITM.

DANE will eventually allow to break this dependency.