I'm saying that Chrome should be enforcing DNSSEC + DANE when using DoT/DoH. I'm not saying that they replace the existing requirements with a different approach but that they should support pinning via DNSSEC + DANE to allow sites to stop trusting CAs for users with DoT/DoH.
Conversation
Many DANE advocates do want it to be available as a full replacement for WebPKI. I'm not suggesting that Chrome should do that. It's usable as either a full replacement or a pinning mechanism. I know Chrome isn't going to drop CT and I'm not proposing that it should be doing it.
2
Replying to
Got it, glad you clarified that.
It doesn't seem as strong as HPKP though, because you're still reliant on trusted third parties with DANE. HPKP let you avoid TTPs entirely, or at least choose the ones you wanted to trust.
1
Replying to
HPKP doesn't work for the first connection or when the pins have expired. DNSSEC + DANE secures the first connection. It relies on DNS as a root of trust, just like WebPKI does for DV. You can choose which TLD operator you want to trust though, instead of trusting all of them.
2
Replying to
True, though you have to trust the DNS root regardless. Also, switching TLDs would really suck if yours turns out to be untrustworthy.
1
Replying to
Many CAs are clearly untrustworthy but are still trusted by browsers because it's too hard to remove them. A website can't choose not to trust CAs for WebPKI. They have to trust all of them. The alternative is not providing things via a website. At least you CAN switch TLDs.
1
1
I think it's crucial to keep in mind that the DNS root and TLD operators are already 100% capable of obtaining valid WebPKI certificates for the websites using them. DANE is not replacing trusting all CAs with trusting TLD + root DNS but rather just removing trusting all CAs.
1
1
2
Consider it a site that uses .ly (Libya) as their TLD. The TLD operator can already take over their DNS and obtain a certificate from a CA like Let's Encrypt. This will appear in CT logs, but it is not misissuance on the part of Let's Encrypt. It helps detect it, and then what?
2
2
Replying to
Browsers would require CAs to block issuance to .ly domains until .ly was considered trustworthy again. This scenario has in fact already been played out with other TLDs!
1
1
Replying to
At which point everyone who used Let's Encrypt with the .ly TLD has their sites go down in ~45 days and has to move TLDs. The government may decide it's time to deploy a root certificate for users to add to all their devices now, which thanks to CA approach allows MITM attacks.
1
Once your certificate expires, you don't even have a working redirect anymore, particularly if you had HSTS preloading and there isn't even a UI to bypass it.
I don't think browsers have it in them to quickly break things to that extent for a TLD as widely used as .ly.
The sites using .ly made their decision to trust that TLD. Other sites aren't harmed by it unless they depend on TLS connections to those sites for security.
Compare to CAs, where EVERYONE is harmed by many sites choosing to use one of the many CAs that's run not very well.