Re: [TLS] Application-Layer Protocol Settings

David Benjamin <> Tue, 21 July 2020 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8069D3A0B3C for <>; Tue, 21 Jul 2020 08:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.498
X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T9d1DO6gni4x for <>; Tue, 21 Jul 2020 08:49:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EAB63A0B3E for <>; Tue, 21 Jul 2020 08:49:12 -0700 (PDT)
Received: by with SMTP id o13so12134190pgf.0 for <>; Tue, 21 Jul 2020 08:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3IrTFsF/VgHlkYRdM24eK+rpDfHEHknL6yVHTzY0Qq0=; b=oLKX31rsr3HDvWGRYp+1ZMX1G+9HlarGxjKf4GMbllWeIpHQrJA8UVUi5nVSCpIFwd B52+vd7gCt6ZcwDcdhSaFCesepU1LDQnrJyVQS9PEzs/vtFUQ58INa1bHi6chpDDWgBc 0Qv5ds4mh05NALolff09NeE1wzc6ldjsEi9vw=
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=3IrTFsF/VgHlkYRdM24eK+rpDfHEHknL6yVHTzY0Qq0=; b=CAJ0xVlivXDjfNJdvmevdur+yIBTUGyR+QY1LPoqfO2WOCOSRHIVTqFil7m6dI3Icv ZZgvSTH3/na0yZnq7Bdo3Az7w8lR1S1bmdJ5Z+puByE0prlTXdQSa6la6oAaMv2um4eE 5xuZ9SKFO+zQMx3+sKJW8bYdNr02a2/CP4ZetESUuPD4jtv9enZdYMnZS2gdAFWWYOto 51XIHpyBHMVvJGRHj9UMwNOWGUskFYk21SETvtc9lBt5XBQ1/36+L6RZVoBqHlwEb7q+ aPYpHbvsUEz14XydZ0wmbpZV0ngdKfIh9hSWXFHAweCRjvckkPsn/kZS9VjE9TF26ZGa t9bA==
X-Gm-Message-State: AOAM532Ppxpz5cgIBftzsAVo8dQQiDrGv/sVbt0T1sn7aeDPJ2Rv+mol A2Rp/CGbTw8ttexCnE+EZU1TgN5yhzA9UE3SBdU7
X-Google-Smtp-Source: ABdhPJyA7KlRU1icX8BjKy50Defz0ftTSQP+gfB2KOI8oGxrh+ZO9FkGA+8VxtME8j/jfUNaC1T95ERQ6/vrFwbeIpA=
X-Received: by 2002:a63:6e4c:: with SMTP id j73mr22550723pgc.182.1595346551847; Tue, 21 Jul 2020 08:49:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 21 Jul 2020 11:48:55 -0400
Message-ID: <>
To: Lucas Pardue <>
Cc: Victor Vasiliev <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000084992b05aaf59022"
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: Tue, 21 Jul 2020 15:49:15 -0000

On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue <>

> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <>
> wrote:
>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <>
>> wrote:
>>> 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.
>> Could you elaborate on this a bit? I'm probably just failing to parse,
>> but I'm not sure which alternative you're suggesting here. (Ah, the wonders
>> of email.)
>> David
> I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why
> my intent was probably unclear. Basically, if ALPS relies on frames for
> per-protocol settings then it has to accommodate the differences in frame
> format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client
> Reliability proposals, the H2 frame needs to populate the frame header and
> it pick stream 0, which doesn't exist until the connection is actually
> made, so seems a bit kludgy. In H3, frames don't have the stream ID so you
> avoid the problem above.
> So my thought was to basically do away with the notion of
> protocol-specific frames in ALPS, and instead define the a common payload
> format that perhaps looks something like bishop-extended-settings [1], a
> series of Type-Length-Value (but without any frame headers). This would
> allow you to encode the old and new settings in a single format, rather
> than needing to delineate things via frames.
> [1] -

Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we
may as well define them however is more idiomatic for the protocol. This
means we automatically can make existing H2 and H3 settings more reliable.
Settings values can also be updated over the course of the connection, so
using frames keeps continuity there. But, yeah, a separate key/value syntax
would work too.

(A small correction, the current Client Hint Reliability proposal allows
ACCEPT_CH to be sent in application data too. Maybe the frontend realizes
the origin's ACCEPT_CH preferences have changed and wants to notify
existing connections. Though I don't consider this feature important. I
doubt most folks, if anyone, will bother with this. Mostly that's how a
SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured
the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.)