Re: Quic: the elephant in the room

Ben Laurie <> Sun, 11 April 2021 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 252013A0E07 for <>; Sun, 11 Apr 2021 07:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qQSSs3Nq6dlL for <>; Sun, 11 Apr 2021 07:38:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EEEB3A0DB2 for <>; Sun, 11 Apr 2021 07:38:45 -0700 (PDT)
Received: by with SMTP id f4so3390658uad.12 for <>; Sun, 11 Apr 2021 07:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zHtiWabxV8f0iHdaAHZGe+RHoMucyGwVF3JJmeBbEQ8=; b=YzPh4Cx+bdhAchvSjPKu8952ui2KArH1SsYgPVzbvkmOsIbajxMhqJMlvp6wCj6Me9 ajWALIQNumMcxjxdGRtxTNypFeY2NEb+5XnqSJeLwVxnvoAQPAwLxSN+OHz+fQcDcNhK gRe8zZq3UGf3NtX6A+IhWRJ9FqIX5rcOajiafb8m00dk5rWFfykKKz/VAxvrWFw2F+hN xK4InzdyCzWLcqVFtVraBVZbEK5W92/ISKRlPr7eVeArid0ibGix5mdyaN5meYQYIDVP Hou66QbV/C9SeuxhCADnq0XdHAEMhTgVS2COZptK87cJakiJh9I3c6S+TmtnAzeo8+wi URBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zHtiWabxV8f0iHdaAHZGe+RHoMucyGwVF3JJmeBbEQ8=; b=Z1jRDocCslkhM8lzbBr5Cff5PW1Uc7cao7BsROEqp3y+jQaWVrJ74vkPu7m/MI14xy l3GnrcQTbAIZZ3I2gitQOYWC5m+YXUlktBIxJrYG+d3IJvjAQvcgmyseampNhyx9ZDBh LusY9bby2dMK8312PkuMTzSePQuFnATgJqbNlf6jxAcRdsU/OXf1EdKs2K1oAQyX1kLr haUI+qyarCWvkIrOvMxW8tJFq4c4DHYfTHVrxZg7TlkqhugsFzHSFIhSutTkwicvN+Da fpjyCnwpHERBzX+jRjPuf8CMdsQ6lPc9pxlh4F3e+y5I3EqgFvtNRrNSDSh97SLJSXxu Yfww==
X-Gm-Message-State: AOAM531EyK7exohjb3K0i8+ANTUaatYzNf51Q8WaVKr7NdGagH6Ojoeb iIVFwlpCEQ8m6k6tZVEYMObf5Duyta7E54cIxT5vNFW1ee0=
X-Google-Smtp-Source: ABdhPJzwWCKd/UasVDz1wgFd8ahMeWkNgF/CCa4RMxtHq3X6gsyudK6Y8lU3DgjWeY+s20bR9fOXMvlCJmRqKtOnXik=
X-Received: by 2002:ab0:2248:: with SMTP id z8mr3422167uan.91.1618151923495; Sun, 11 Apr 2021 07:38:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <20210410175712.GF9612@localhost> <>
In-Reply-To: <>
From: Ben Laurie <>
Date: Sun, 11 Apr 2021 15:38:32 +0100
Message-ID: <>
Subject: Re: Quic: the elephant in the room
To: IETF Discussion List <>
Content-Type: multipart/alternative; boundary="000000000000983dbc05bfb35a88"
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 14:38:57 -0000

On Sat, 10 Apr 2021 at 19:09, Viktor Dukhovni <>

> > On Apr 10, 2021, at 1:57 PM, Nico Williams <>
> 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).