Re: [TLS] Application-Layer Protocol Settings

Lucas Pardue <> Mon, 20 July 2020 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AD3D3A0F8F for <>; Mon, 20 Jul 2020 14:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.018
X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NS4OjnVDS-lT for <>; Mon, 20 Jul 2020 14:03:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8E1B3A0F8C for <>; Mon, 20 Jul 2020 14:03:52 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxcuK-0001m9-NN for; Mon, 20 Jul 2020 21:01:08 +0000
Resent-Date: Mon, 20 Jul 2020 21:01:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxcuJ-0001lO-HM for; Mon, 20 Jul 2020 21:01:07 +0000
Received: from ([2a00:1450:4864:20::330]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxcuH-0001K6-Nt for; Mon, 20 Jul 2020 21:01:07 +0000
Received: by with SMTP id o8so787446wmh.4 for <>; Mon, 20 Jul 2020 14:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Sum2hAaARDzUflC3+6o8/CVvM+iqsdqXyL02Ze5PXo=; b=qOqMpzubsQiUgacz/8rb4XU70A9od8ZYkw/bBeQ+O9TSRiMK1aZ35RjkaFN0iEN0yr 5SwHolWvm+3Vwlyz0FKq+oc5LLR+PGPUgtxfkYdqKlG36xU05DzG8RKk0B9wx/ZSczf5 xkfRVd5C3QZVuj3h0KslkFis87Fs61OfUYBEUbIhhRV+hQfu8LuxWJmZ2Pz2JXUr1pgI rZ9YKWtJ2hYEpHunx/rdF7Kp2xbw2GYkitqrift5neZB+8lA4LWWcbKbcoJua7nHXDNQ 9EtRWV1e+Fmuhm/X3zjNo+n3AN6bO+kkJ2B4ZAzGBL0980Bilm/sPtFFzPc8K9YWKrl+ CaOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1Sum2hAaARDzUflC3+6o8/CVvM+iqsdqXyL02Ze5PXo=; b=ExufUEkaBGkfha8/ZVaDaMeOb8uRoXZ4t71dmC7H72+QnTotji5j1SVv2qWLiYBF3C cZIlWiSmJ0Ogyu+EEM5UcW6grSxSb7GH7jVd4XajhI7vN3K9qPABc/LDSYLBpU1jwzS4 G3izzfwsCqt2V8yOE6Mh8FLioeNK8cNohPebvJZQ5QM2VOIgxO6o7BVvl99RCw5LC24O NIQhCaWENcWZ/s1UYrZFF5xwENvIrcwiBjiK+kvKJHsWdjD+5lRCGVWXpQ0eweYYiMfT uObS0mDymsw2rorDD8MiE7gw1AvFGOWvC7aUi+gjTmMwqVgz5fdE2Jg8Nbl1/oiQLzvI 9Nww==
X-Gm-Message-State: AOAM531YglR/Z2G5uvv/9tgM81hSTBytU/ruAe67WrWahu+AO0NIbYAl UYuE745nFr4cVzTIF0gPuJkPAtuBJzwcVkOe2mE=
X-Google-Smtp-Source: ABdhPJzfXwHgtiMFS1DSMX5PzFWl6QaK8IhsDOS975V+E1VUie1vUmSJWhQjiC9ihCRnz5cfbYWDpyckg90eQmwMW7c=
X-Received: by 2002:a1c:6788:: with SMTP id b130mr1056554wmc.100.1595278854297; Mon, 20 Jul 2020 14:00:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Mon, 20 Jul 2020 22:00:48 +0100
Message-ID: <>
To: David Benjamin <>
Cc: Victor Vasiliev <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000006d9ace05aae5cd11"
Received-SPF: pass client-ip=2a00:1450:4864:20::330;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Scan-Sig: 1jxcuH-0001K6-Nt d1a8ed2a1fb5ec6129e7ff9cbd1ddea3
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37896
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, 20 Jul 2020, 21:38 David Benjamin, <> wrote:

> On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv=
>> wrote:
>> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <>
>> wrote:
>>> Hi Victor,
>>> It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in
>>> your original email. I was reading it in the context of David Benjamin's
>>> thread on Client Hint Reliability [2]. There's a couple of things that
>>> surprised me when reading both drafts:
>>> 1. ALPS in HTTPS actually supports more than just exchanging Settings
>>> Parameters, it can actually hold a series of frames. It's just that ALPS
>>> only defines SETTINGS to be allowed, and Client Hints Reliability wants to
>>> add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the
>>> idea of supporting any old frame in the TLS handshake, SETTINGS are at
>>> least reasoned about in terms of how they are remembered for the purposes
>>> of 0-RTT.
>> It explicitly bans all existing frames that are not SETTINGS.  The
>> problem here is that SETTINGS only supports integral values, so we'd be
>> limited to those if we make ALPS just SETTINGS.
> Right, concretely there is an "Allowed in ALPS" column added by Victor's
> ALPS document, which my document sets for the new frame. Old frames weren't
> designed with ALPS in mind, so the ALPS document needs to make a decision.
> New frames can reason about the implications of opting into ALPS and do so.
> As Victor notes, it's only a new frame because we got SETTINGS values
> wrong and, per earlier discussion, the extension point we currently have is
> new frames. If we want something even more restrictive, we could instead
> revive draft-bishop-httpbis-extended-settings, say only SETTINGS and
> EXTENDED_SETTINGS are allowed, and close it there. But I think the new
> column works fine and matches how this sort of thing usually works.

That makes sense but I guess I don't see the point in defining a new thing
that contains frames that are never sent on streams. That is, if these are
connection settings, just send the payload. Unframed extended settings
might get you there, if you can find a way to encapsulate conventional
settings inside them, then all the better.


/tls <>