Re: Quic: the elephant in the room

[Nico Williams <[e-mail]>]

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
--