Re: Quic: the elephant in the room

[Ben Laurie <[e-mail]>]

On Sat, 10 Apr 2021 at 19:09, Viktor Dukhovni <[e-mail]>
wrote:

> > On Apr 10, 2021, at 1:57 PM, Nico Williams <[e-mail]>
> 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.
>
> Ben's claim that CAs are "more secure" than DNSSEC is demonstrably
> in error in a world where all that CAs do is issue DV certs that
> attest to "domain control".
>

If that were the only consideration, I would agree. However, as I replied a
few minutes ago, the security of the operators is also important and it was
that I was referring to.


>
> If you don't trust the ICANN root, you can't trust DV certs, since
> all they do is memoise some DNS-derived data you don't trust.  Indeed
> it takes DNSSEC (and CAs honouring DNSSEC-signed CAA records) to somewhat
> improve the rather weak assurance that DV provides.
>

Incorrect - CT would reveal ICANN's misbehaviour.


>
> Perhaps CT adequately hardens this model for Google's domains, if
> they're sufficiently vigilant to detect unauthorised certificate
> issuance (after the fact), but for the rest of us, tracking the
> CT logs is not actually practical.
>

I do agree that we really also need verifiable maps of domain -> certs
which would make it easy for anyone to monitor their own domains. However,
there are also plenty of services that will do this tracking for you (yes,
you do have to trust them to behave themselves).