Re: Quic: the elephant in the room

Nico Williams <nico@cryptonector.com> Mon, 12 April 2021 17:25 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 569653A0DC5 for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 10:25:52 -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 GQUbbUHPJwJK for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 10:25:47 -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 866B03A0DC4 for <ietf@ietf.org>; Mon, 12 Apr 2021 10:25:47 -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 024127024C5; Mon, 12 Apr 2021 17:25:46 +0000 (UTC)
Received: from pdx1-sub0-mail-a47.g.dreamhost.com (100-101-162-32.trex.outbound.svc.cluster.local [100.101.162.32]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 19697702558; Mon, 12 Apr 2021 17:25:45 +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.101.162.32 (trex/6.1.1); Mon, 12 Apr 2021 17:25:45 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Descriptive-Chief: 22aca7c77904ad82_1618248345817_535323544
X-MC-Loop-Signature: 1618248345817:983138191
X-MC-Ingress-Time: 1618248345816
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 D3FA28ACC9; Mon, 12 Apr 2021 10:25:44 -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=ZM/nIVHT3PQrGu jQnFB3+xBjU2c=; b=ChOmK6jFl9djKHFQpVPv9+0Q2Wfvs5Dc3mwT99zCW0JjbW +NujJWCOgH+ZTS8dyDfezgvTRijPYiSMDm2Xqh4qB5hZgs754BBm1UDpL8TQ5JdK sJcApoNDeR6C/RlMX54GO0r8fj9Kukyy8Uyn0RspvlcnSuLUIVhvgRjB/0y/0=
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 2B0CA8ACCA; Mon, 12 Apr 2021 10:25:40 -0700 (PDT)
Date: Mon, 12 Apr 2021 12:25:37 -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: <20210412172537.GU9612@localhost>
References: <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> <20210412161009.GS9612@localhost> <CAMm+LwiLA0ynqFoniSfn0TumFaQB2SS-OKrtkjyJJonJF7Hq5w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm+LwiLA0ynqFoniSfn0TumFaQB2SS-OKrtkjyJJonJF7Hq5w@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zaQsKCJrFQyrtGMTL4afV6JVPxI>
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 17:25:52 -0000

On Mon, Apr 12, 2021 at 12:48:28PM -0400, Phillip Hallam-Baker wrote:
> On Mon, Apr 12, 2021 at 12:10 PM Nico Williams <nico@cryptonector.com>
> wrote:
> > "No magnification DDoS please"
> 
> Oh, I have that built into the key exchange phase.

Sure.  We've talked about this before.  The DNS data model can't really
change, but the protocol can.  We're already seeing the protocol change
with DoT and DoH.

> > 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.
> 
> If I was still doing PKIX, my long term plan would be to get rid of OCSP
> and move to short lived certs created using thresholded techniques. But I
> am not and nobody is paying me to think about that world any more.

Forget the details of x.509/PKIX/ASN.1 and all of that.  A lot of the
concepts remain the same.  PKIX, for all its warts, got some things
right that must not get lost in the shuffle.  First of all, naming must
be "typed" (I don't mean structured, but that you have to know if
"name@domain" is an email address or a Kerberos principal name).
Second, you need to be able name more than one name.  Third (really,
first), name constraints!  And so on.  Ultimately, certificates need to
be signed big bags of extensions, and in a post-PKIX world those things
should all be strings.

Nico
--