Note that the CA which did this is trusted only by Microsoft. The other major root programs (Mozilla, Chrome, Apple) manage their root programs much better and don't trust CAs like this.
Also, this CA is part of the EU's Trust List, so had the EU's original eIDAS/QWAC proposal gone through, Mozilla, Chrome, and Apple would have been required by EU law to trust this CA also.
This exemplifies why DoH is not enough, and why we need something like DNSSEC to prevent big brother from tampering with your internet connection.
Yes, DNSSEC as specified by the RFC is flawed and many TLDs/countries don't bother with it, let's skip the usual discussions, but something like it would make tampering obvious.
To prevent regular TLS MitM attacks, we have HTTPS pinning (though HKPK died in browsers), but most DNS, even with layered encryption on top of it, has "trust me bro" as an authenticity model.
xoa · 1h ago
It does sometimes feel like lack of secure chain DNS, however exactly implemented, is one of the original sins of the modern internet that has caused a lot of headaches and layers upon layers of bandaids ever since. Doesn't mean it'll ever be solved of course, the legacy support issue at this point is pretty brutal. But DNS has already effectively ended up as the root of trust for a lot of auth anyway, if an attacker somehow gets access to someone's registrar account they can from there trivially bootstrap. Rather than so many root CAs that can also issue certs for any domain, seems like it'd be pretty nice if we could just depend on DNS and then have an "authorizedCA" record or whatever and stick any public certs(s) in their the domain owner desired. Could be a 3rd party, could be their own CA, but the only CAs that could issue a cert for that domain would be the one's the domain owner wanted which is how it's supposed to be anyway right?
Ah well.
agwa · 1h ago
I would caution against generalizing from the actions of a CA that only Microsoft is willing to trust. This incident says way more about Microsoft's mismanagement of their root store than it does about the WebPKI security model.
Also, DNSSEC tampering is no more obvious than WebPKI tampering (how would anyone know if Verisign served a rogue DS record for someone's .com domain to certain resolvers?). Just as with WebPKI, you need a transparency system if you want to make tampering discoverable. (Such a transparency system has been proposed for DNSSEC but went nowhere.)
Note that the CA which did this is trusted only by Microsoft. The other major root programs (Mozilla, Chrome, Apple) manage their root programs much better and don't trust CAs like this.
Also, this CA is part of the EU's Trust List, so had the EU's original eIDAS/QWAC proposal gone through, Mozilla, Chrome, and Apple would have been required by EU law to trust this CA also.
Yes, DNSSEC as specified by the RFC is flawed and many TLDs/countries don't bother with it, let's skip the usual discussions, but something like it would make tampering obvious.
To prevent regular TLS MitM attacks, we have HTTPS pinning (though HKPK died in browsers), but most DNS, even with layered encryption on top of it, has "trust me bro" as an authenticity model.
Ah well.
Also, DNSSEC tampering is no more obvious than WebPKI tampering (how would anyone know if Verisign served a rogue DS record for someone's .com domain to certain resolvers?). Just as with WebPKI, you need a transparency system if you want to make tampering discoverable. (Such a transparency system has been proposed for DNSSEC but went nowhere.)