Re: [TLS] Application-Layer Protocol Settings

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 882C03A0F90 for <>; Mon, 20 Jul 2020 14:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOkmR8KzKNGO for <>; Mon, 20 Jul 2020 14:00:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBBD33A0F8F for <>; Mon, 20 Jul 2020 14:00:55 -0700 (PDT)
Received: by with SMTP id f139so810689wmf.5 for <>; Mon, 20 Jul 2020 14:00:55 -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=pz3usjzNUNuWrbRMYiji29zl76Ugte/+ZTV+1YlZVZK6U83FWLibGvULojEUy5CIKZ 1BH4DLk/UpheKVUCh99h2n5h10FBIXqpQbJMPHcfTSuxtKwkhc3uj01CiULQ8mtm5Anl BtoGmiiN6YAHpVvtufI+ng7iHhTdSZRVdJSmUKfNs+edjnbfUDZYlspUZ4n01hYktrl9 EW8CgetPwf5tb8ANAZ/yGgDwmEOlKE20A0bg5zYw0KrDujGqk5huFFYYg7fMj4cJsV98 HKs8XR+SKhoYcnU5VVeQ3p8EgXJaswzIivkPbZAZ18tAq3MBwWWiojhMnzWuXQ5qlRwA tPIg==
X-Gm-Message-State: AOAM530z8ZfRZLiuSAPSL0UB3cefk7sFwPZJO2D/+aKD3A4nTnw/VZ5b 6E7LNXwfdZe98HCxDnYI6e+37azoVc0625debxE=
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"
Archived-At: <>
Subject: Re: [TLS] Application-Layer Protocol Settings
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2020 21:00:58 -0000

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 <>