Re: Quic: the elephant in the room

Nico Williams <nico@cryptonector.com> Mon, 12 April 2021 16:10 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 4A4663A2443 for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 09:10:30 -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_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: 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 xx1JUtRNlCWl for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 09:10:25 -0700 (PDT)
Received: from hamster.birch.relay.mailchannels.net (hamster.birch.relay.mailchannels.net [23.83.209.80]) (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 6391C3A2440 for <ietf@ietf.org>; Mon, 12 Apr 2021 09:10:25 -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 85DEE482E29; Mon, 12 Apr 2021 16:10:15 +0000 (UTC)
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (100-96-16-47.trex.outbound.svc.cluster.local [100.96.16.47]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D7DFE483004; Mon, 12 Apr 2021 16:10:14 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.47 (trex/6.1.1); Mon, 12 Apr 2021 16:10:15 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Trouble-Slimy: 15f5bc196debde29_1618243815151_975229754
X-MC-Loop-Signature: 1618243815151:1118488545
X-MC-Ingress-Time: 1618243815151
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a47.g.dreamhost.com (Postfix) with ESMTP id 873C98ACCD; Mon, 12 Apr 2021 09:10:14 -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=aRPveNHqww57rq hB+ldkAgMAgfY=; b=DYYSmbz684nVekOlDNhije7rBDTHTKijOuWh4LcVzCOjp+ B2CRu/dEH8hJfLCEjPoGLkJVctOTxHIyi7jt0Z6IBshTPeXOKpdCzGqddjDZPysx KVg8AbDPVOQI30JhFEqFZbQWBD5WRTdqLy29iUN7ZtnFPTOYw3GjBvtXCn3wc=
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-a47.g.dreamhost.com (Postfix) with ESMTPSA id 9190B8ACCA; Mon, 12 Apr 2021 09:10:13 -0700 (PDT)
Date: Mon, 12 Apr 2021 11:10:10 -0500
X-DH-BACKEND: pdx1-sub0-mail-a47
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Michael Thomas <mike@mtcc.com>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Quic: the elephant in the room
Message-ID: <20210412161009.GS9612@localhost>
References: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com> <CAMm+Lwhi8xwFgZJL7jod2g4urZt_f+dm0tNi+3y1osqOfch2mQ@mail.gmail.com> <3593a01f-73f4-7d03-a85b-dff64a8b070e@mtcc.com> <506A780B-9C0D-4F4A-B045-098F6152F4DB@akamai.com> <14cd802e-2a1b-97d4-c80d-b57f93e8cc21@mtcc.com> <E4374100-265E-4426-9F9A-AC437DA31D2B@depht.com> <15059e21-b7c2-4211-869e-df3ffdf7c34a@mtcc.com> <CAMm+LwgnoqXKNSKxt0-rDa8ze6J9LsZz0jVeogBXAWNDveC_ZQ@mail.gmail.com> <20210412155121.GQ9612@localhost> <CAMm+LwhndGSN=V3j8-DAYo5WdtSJXHCh7TyQ3uZXEKn_0AoA6g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm+LwhndGSN=V3j8-DAYo5WdtSJXHCh7TyQ3uZXEKn_0AoA6g@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2lB0BTbiD-cqZs2GHPbkJwwcA1c>
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: Mon, 12 Apr 2021 16:10:30 -0000

On Mon, Apr 12, 2021 at 11:59:58AM -0400, Phillip Hallam-Baker wrote:
> On Mon, Apr 12, 2021 at 11:51 AM Nico Williams <nico@cryptonector.com>
> wrote:
> > On Mon, Apr 12, 2021 at 11:33:29AM -0400, Phillip Hallam-Baker wrote:
> > > Or replace the DNS resolver protocol with a privacy protected one
> > > in which a single request packet can be answered by multiple
> > > response packets.  This maintains the 'stateless' nature of DNS
> > > queries but allows responses of 1-32 packets.
> >
> > As long as it's not over UDP, or otherwise first has a return
> > routability check.
> 
> I don't follow.

"No magnification DDoS please"

> > > Then a query to the responder can return the A record, the AAAA
> > > record, the SRV record, any relevant TXT and TLSA records [...]
> >
> > Kinda like "any" queries.
> 
> Not quite because of 1) the interaction of prefixes and 2) you only
> need data for the one host you connect to.

Thus "kinda" :)

> > >                                         [...] and the entire cert
> > > chain for one particular host chosen by the responder.
> >
> > You get better security properties (w.r.t. possible compromised root
> > or ccTLD/TLD keys) if the resolver finds the DNSSEC chain on its own
> > using qname minimization than you get with stapling, but I agree
> > that stapling is a performance win.  We'll really want transparency
> > for DNSSEC if we do any kind of full chain stapling.
> 
> SCVP introduced a distinction between path discovery and path
> validation.  Both can be very useful.

Yes, exactly.  But for PKIX path discovery is not possible without
directories, but DNS _is_ a directory, so you get to do path discovery.
And unlike PKIX, there is only one possible path (well, at most as many
paths as there are labels in the domainname, minus 1, plus any sub-paths
due to CNAME RR chasing).

> If you have a low level IoT device, you are probably better off doing
> path math properly in one trusted device in your network than relying
> on whatever embedded code is running in your toaster.

Absolutely.  There is a trade-off to make.  Low-power && low-value RPs
should prefer stapling, or even a local caching recursive resolver to do
all the lookups and signature verification too.

Nico
--