Re: Quic: the elephant in the room

Nico Williams <> Sat, 10 April 2021 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7307D3A1939 for <>; Sat, 10 Apr 2021 12:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2AwA6Pz6FZTf for <>; Sat, 10 Apr 2021 12:50:56 -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 9A5713A193B for <>; Sat, 10 Apr 2021 12:50:56 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 1977D1E1D5A; Sat, 10 Apr 2021 19:50:54 +0000 (UTC)
Received: from (100-101-162-32.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id AA2251E1D14; Sat, 10 Apr 2021 19:50:53 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by (trex/6.1.1); Sat, 10 Apr 2021 19:50:54 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Chief-Squirrel: 5f89728d322c094b_1618084253960_2903258196
X-MC-Loop-Signature: 1618084253959:1826842731
X-MC-Ingress-Time: 1618084253959
Received: from (localhost []) by (Postfix) with ESMTP id 3DD027E431; Sat, 10 Apr 2021 12:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to;; bh=gw/5jZKEmuXIZ996Fo2G0cSg4mQ =; b=MNegvueCOXYyYyvh2/8B/aAe2ll1KQud5Y0eBa9V6Des0eOgnrHO0HuVrE/ Cta0WyFOuQzr+luOpdapn7sOFVFlJwoED8Gc+T5FGhdAC5otqXSaVv+Yl/K5zpr7 zeIzFhGeS4YQy6JfCf0AlechccIUd7Qy0g+aC5RggYNfp4Q4=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id E73AB7E42F; Sat, 10 Apr 2021 12:50:52 -0700 (PDT)
Date: Sat, 10 Apr 2021 14:50:49 -0500
X-DH-BACKEND: pdx1-sub0-mail-a30
From: Nico Williams <>
Subject: Re: Quic: the elephant in the room
Message-ID: <20210410195048.GG9612@localhost>
References: <> <> <> <> <20210410175712.GF9612@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
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: Sat, 10 Apr 2021 19:51:01 -0000

On Sat, Apr 10, 2021 at 02:08:30PM -0400, Viktor Dukhovni wrote:
> 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 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.
> 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.

Indeed, CT works only if people bother to do enough log checking to
increase the risk -real and perceived- to malefactors with access to CA
credentials.  CT can fail to get there generally, leaving us with the
same old name-constraint-less, multi-root WebPKI.

CT is not the answer, and it's not even an answer.  CT might help, and
it's better than nothing, but it's certainly not better than also
addressing the other issues, and it's not better than only addressing
the other issues either.

If QUIC were to depend on DANE, the result would be a shot in the arm to
DNSSEC deployment, which would instantly address the two biggest
problems with WebPKI.