Re: Quic: the elephant in the room

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 10 April 2021 18:08 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2683A1766 for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 11:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gd2nTA_X12Q for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 11:08:32 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919A63A1768 for <ietf@ietf.org>; Sat, 10 Apr 2021 11:08:32 -0700 (PDT)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 64309B88BE for <ietf@ietf.org>; Sat, 10 Apr 2021 14:08:31 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: Quic: the elephant in the room
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20210410175712.GF9612@localhost>
Date: Sat, 10 Apr 2021 14:08:30 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf@ietf.org
Message-Id: <926C5F27-E011-4809-88DB-DBC9A8976D01@dukhovni.org>
References: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com> <CAMm+Lwhi8xwFgZJL7jod2g4urZt_f+dm0tNi+3y1osqOfch2mQ@mail.gmail.com> <3593a01f-73f4-7d03-a85b-dff64a8b070e@mtcc.com> <CABrd9STZXonBDvWB7Z36H2mD20Juubc01TUmEvpfWkvJggQVOQ@mail.gmail.com> <20210410175712.GF9612@localhost>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ARz8S_9ewM5SBqyacjD3KZnw2To>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Apr 2021 18:08:37 -0000

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

-- 
	Viktor.