Re: Quic: the elephant in the room

Viktor Dukhovni <> Sun, 11 April 2021 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D66453A229A for <>; Sun, 11 Apr 2021 16:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RSWg6gIVRCu6 for <>; Sun, 11 Apr 2021 16:05:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C1243A2299 for <>; Sun, 11 Apr 2021 16:05:50 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 4CE0AB93EA; Sun, 11 Apr 2021 19:05:49 -0400 (EDT)
Date: Sun, 11 Apr 2021 19:05:49 -0400
From: Viktor Dukhovni <>
Subject: Re: Quic: the elephant in the room
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Apr 2021 23:05:53 -0000

On Sun, Apr 11, 2021 at 11:39:04PM +0100, Ben Laurie wrote:

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

Well the point (already made upthread, ...) is that if domain control is
compromised, so is certificate issuance, Let's Encrypt will happily
issue a certificate for a domain that's been taken over.  With CT
presently ineffective for most domains, the upshot (as stated upthread)
is that WebPKI is at least as vulnerable to compromise as DNS.

Now with DNSSEC and a registrar chosen for good security practices, one
can do better than DV.  True, there's no CT for DNSSEC, but in fact it
is considerably more difficult to surreptitiously compromise DNSSEC
without the domain owner noticing than it is to obtain a certificate
from the least meticulous CA.

There are of course pros/cons for CT and pros/cons for DNSSEC, but my
take is that architecturally DNSSEC is better suited for securing the
typical domain on the public Internet.  Adoption has been hampered
difficult KSK enrollment rollover, immaturity of tooling and by habitual
cynicism from plausibly authoritative voices.

Now in fact the tooling has improved dramatically in the last year or
two (see e.g. BIND 9.16 key management policies), and
registries/registrars are starting to implement CDS/CDNSKEY, see e.g.
recent talks by Brian Dickson of Godaddy about their plans.

Adoption has risen significantly over the last couple of years as well,
though sure, not yet at the pace I'd ultimately like to see.

Which leaves just the naysaying, which sounds mostly like a broken
record, that is disconnected from the changing realities on the
ground.  My take on the naysaying is: lead, follow or get out of
the way!.

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

I recognise the reality of this, and therefore don't give as much weight
to the efficacy CT as you do.  The main thing that helps is short(er)
term certificates.  Perhaps LE could move from 90 days to 30 days or
even 7 days, but that would sure stress the CT logs even further.

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

I agree it can be effective for well-resourced highly automated
operations, like e.g.  I am sceptical that it is
adding any value for the "average" domain.