Re: Quic: the elephant in the room

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 12 April 2021 03:39 UTC

Return-Path: <hallam@gmail.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 F0D823A2B73 for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 20:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 D7dJ80KDTlNm for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 20:39:20 -0700 (PDT)
Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B094D3A2B70 for <ietf@ietf.org>; Sun, 11 Apr 2021 20:39:20 -0700 (PDT)
Received: by mail-yb1-f172.google.com with SMTP id c195so13498196ybf.9 for <ietf@ietf.org>; Sun, 11 Apr 2021 20:39:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BU4M3u2hDmsBj1uZXNW3HtmIRcSPArnWCf91OiQQ0ds=; b=D4+IimkwBVBz4xWsP8s93gPp94lTk/JTNOPBfam8aBfYDRpIVeFt530aTIL1zU9B3B rko0tz1cgrSSP8gAb6UBUfs1dPLVMdsSkrzvEDBgz2OvBk3sk+Px7+UtEPbRHXmxeC/c eivE5uEwX7UJIct48yZHScSGwNYKyilWN78ovkdLRme4uBAA/rVYa6A8QhT1lqMjycRY yXeizFdHnM9G6wgbTl9qTN6n81Nt7zcwJWnAj73hsYXNCckxqDGLgF/4hSEg2V1SGd6S 9MlJQLYVliKczy1FUZLo7NljMgqcPzJ5bzyRqQVezTZ5wi0Js0JaeoAGIM6rGrTVqqpG 2ZNg==
X-Gm-Message-State: AOAM530g9+MGEaTDiSgzMo41jMUwTRBUxi9DlykmqPNxXWeWFC4m3RM3 E7kidlViRKsjmfdNjpQDQxdAIM0/IYo1vlTD5Kg=
X-Google-Smtp-Source: ABdhPJydwtI0ZI4Op+m45dIooziI+CMGWjsZkaHzgiMezAbWc9HyFbIm6Ox1xg+vIm2/8XyAG7Ypalc35XVjHEL1dZ4=
X-Received: by 2002:a25:850b:: with SMTP id w11mr35352774ybk.518.1618198759448; Sun, 11 Apr 2021 20:39:19 -0700 (PDT)
MIME-Version: 1.0
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> <20210411195854.GL9612@localhost> <94707E61-D7D2-4494-B88C-E229C8D8F3E4@akamai.com> <20210412002634.GO9612@localhost> <31A7A397-747D-4099-A3A3-F845137022BD@akamai.com> <20210412021224.GP9612@localhost>
In-Reply-To: <20210412021224.GP9612@localhost>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sun, 11 Apr 2021 23:39:07 -0400
Message-ID: <CAMm+Lwi6hnvJjhexe4DzEZZ3WJByE9R1YmQAdPbq_O4f4H7w1Q@mail.gmail.com>
Subject: Re: Quic: the elephant in the room
To: Nico Williams <nico@cryptonector.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ba52a05bfbe421f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/K0msNwFn4LRWNGJo8PB2wX9DElo>
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 03:39:26 -0000

On Sun, Apr 11, 2021 at 11:00 PM Nico Williams <nico@cryptonector.com>
wrote:

> On Mon, Apr 12, 2021 at 01:54:23AM +0000, Salz, Rich wrote:
> > >    You publish TLSA RRs for the new one and after the switch you
> delete the
> >     ones for the old one.  You can have more than one TLSA RR in a TLSA
> >     RRset.
> >
> > Thanks for the explanation.  I don't know enough DNSSEC to know if
> > that's actually deployable, but okay
>
> You can tune down TTLs before the change, etc.
>
> Perhaps there is room for a certificate extension that says "invalidate
> cached TLSA RRs cached before this $timestamp" (the timestamp might even
> be the certificate's notBefore).  Then there would be no need to tune
> down TTLs.
>

Formula One autosport provides a model for what is and is not possible.

If you want to achieve the very highest level of performance it is
necessary to abandon the traditional engineering approach by which systems
are broken down into independent components and either consider different
decompositions that yield better performance or to abandon the
compartmentalization entirely and optimize across multiple concerns at
once. Thus the engine block is not merely the container for the pistons and
bearings, it is a structural member for the vehicle, a part of the
aerodynamic systems, etc. etc.

If you start with the assumption that you want to encrypt the
client-resolver lookup for privacy then you are going to be making a
breaking change there. Once a breaking change is proposed, we should seek
to absolutely maximize the value we get in return.

Omnibroker was a proposal that would have allowed the entire trust path to
be cached along with the DNS discovery data. Combine DNS resolution with
SRV/TXT policy publication, with SCVP delegated path discovery and apply
DNSSEC to the ensemble and for the cost of a single IP round trip to the
omnibroker and you can receive the network endpoint, the TLS credential
path in order so all the RP needs to do is to check the workings, and a
shared secret to encrypt the initial TLS handshake.

One round trip would save you many.