Re: Quic: the elephant in the room

[Ben Laurie <[e-mail]>]

On Sun, 11 Apr 2021 at 23:33, Viktor Dukhovni <[e-mail]>
wrote:

> On Sun, Apr 11, 2021 at 11:18:39PM +0100, Ben Laurie wrote:
>
> > > But any compromise of a registrant, registrar or registry also
> > > compromises CA certificate issuance.  The CAs are redundant so
> > > long as the attestation they're performing is "domain control".
> >
> > CT makes that untrue. Why is this not obvious?
>
> Because:
>
>     * CT is after the fact, plausibly too late.
>

And the on time DNS version is...?


>
>     * As I mentioned before, CT is often impractical for
>       typical domains != google.com.
>

Agree we need more.


>
>       - They need to track the CT logs
>       - They need to keep track of all legitimately issued certificates.
>

You have a suggestion that does not need this?


>       - They need to detect unauthorised issuance quickly and have
>         a mechanism in place to demand revocation.
>       - Clients need to actually support CRLs, OCSP, ...
>
>       There's an awful lot of preconditions there for CT to actually be
>       effective in practice.
>

CT has been very effective in practice, despite these caveats. I do agree
there are problems it doesn't inherently solve.


>
> > > > Also, DNS has the same plethora of authorities with varying
> > > > security responsibility.
> > >
> > > Choose a security-conscious registrar, and apply registrar lock, and
> any
> > > other available/applicable options to prevent unauthorised changes to
> > > domain registration metadata.
> >
> > Of course anyone can trivially figure this out. Not.
>
> It certainly isn't a secret, has been discussed on many lists over the
> years, but I don't know of a canonical place to find this advice.  We
> could publicise this better, not sure whether an IETF BCP would be the
> right mechanism.  Yes, you're unlikely to learn this from a discount
> registrar competing only on price and not on quality/security of service.
>
> --
>     Viktor.
>
>