Re: Quic: the elephant in the room

Nico Williams <nico@cryptonector.com> Sat, 10 April 2021 17:57 UTC

Return-Path: <nico@cryptonector.com>
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 BCB8D3A1719 for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 10:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 UedqSc-J5qpZ for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 10:57:21 -0700 (PDT)
Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) (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 75C6E3A16D2 for <ietf@ietf.org>; Sat, 10 Apr 2021 10:57:21 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 70F7C1E25D3; Sat, 10 Apr 2021 17:57:20 +0000 (UTC)
Received: from pdx1-sub0-mail-a31.g.dreamhost.com (100-96-27-157.trex.outbound.svc.cluster.local [100.96.27.157]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 32BEA1E2724; Sat, 10 Apr 2021 17:57:18 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a31.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.27.157 (trex/6.1.1); Sat, 10 Apr 2021 17:57:20 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Wiry-Fumbling: 5e0ae89c1f7a13ec_1618077440296_714050259
X-MC-Loop-Signature: 1618077440295:630111919
X-MC-Ingress-Time: 1618077440295
Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id F067F7E638; Sat, 10 Apr 2021 10:57:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KKXONX3nQjhlpC m3554Ve+6Ktww=; b=B8cjwRdj7lJqgC5BpUdVOLUcgcqLsZHnneCoEZmHnnrXae aPdoF9A0UVrDq2W4DzLFlxAeynShx96mRGRTKpeywfROXvuKRtl6zI/cmtb0rh51 esZjVXtmiTkMUy+hJ0HUv0WisNJHzssPh3wUWMEZY60gAyzHz1hEG2vio212g=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id D8CEB7F0E6; Sat, 10 Apr 2021 10:57:15 -0700 (PDT)
Date: Sat, 10 Apr 2021 12:57:13 -0500
X-DH-BACKEND: pdx1-sub0-mail-a31
From: Nico Williams <nico@cryptonector.com>
To: Ben Laurie <benl=40google.com@dmarc.ietf.org>
Cc: Michael Thomas <mike@mtcc.com>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Quic: the elephant in the room
Message-ID: <20210410175712.GF9612@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABrd9STZXonBDvWB7Z36H2mD20Juubc01TUmEvpfWkvJggQVOQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XSfabTRviI0u4xZkKeVCTDqmf0k>
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 17:57:27 -0000

On Sat, Apr 10, 2021 at 10:29:42AM +0100, Ben Laurie 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.  This alone is not enough because resolvers
generally send the full qname to every DNS server on the resolution
path, so . and ccTLDs get a chance to impersonate if they want to, but...

...second, using qname minimization makes it very difficult for root
zone or ccTLD operators to mount impersonation attacks because they
can't know the full qname, so if they want to impersonate, they have to
impersonate all qnames you end up asking for, not just the one target.
It can be done, of course.  I imagine something like a stingray device
that is preloaded with .'s signing keys and so can MITM everything,
though that would be an enormous risk to the device's operators.

I expect an objection about how many round trips qname minimization
adds.  Though if you're not hitting caches then you have those extra
round trips anyways, and recursive caching resolvers should get the full
qname, so maybe qname minimization is not a performance disaster.

> Could be fixed with DNS Transparency, of course.

Well, yes, that could and should be done.

Nico
--