On Sat, 10 Apr 2021 at 19:09, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
> On Apr 10, 2021, at 1:57 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> 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).
