On Sat, Apr 10, 2021 at 10:29:42AM +0100, Ben Laurie wrote: > When I was designing Certificate Transparency, Chrome ruled out any side > channel communications requirement during handshake. Given that DNS is > required anyway, perhaps this would be different. However, the other > problem is introducing DNS as a trust root - the DNS hierarchy is > considerably less secure than CAs were even before CT but now it's really a > very poor option in comparison. I disagree with that last sentence. First, having a PKI with hard naming constraints and a single root (though with alternatives supported) is considerably better than WebPKI, which has neither of those. This alone is not enough because resolvers generally send the full qname to every DNS server on the resolution path, so . and ccTLDs get a chance to impersonate if they want to, but... ...second, using qname minimization makes it very difficult for root zone or ccTLD operators to mount impersonation attacks because they can't know the full qname, so if they want to impersonate, they have to impersonate all qnames you end up asking for, not just the one target. It can be done, of course. I imagine something like a stingray device that is preloaded with .'s signing keys and so can MITM everything, though that would be an enormous risk to the device's operators. I expect an objection about how many round trips qname minimization adds. Though if you're not hitting caches then you have those extra round trips anyways, and recursive caching resolvers should get the full qname, so maybe qname minimization is not a performance disaster. > Could be fixed with DNS Transparency, of course. Well, yes, that could and should be done. Nico --
