Re: [TLS] Application-Layer Protocol Settings

David Benjamin <> Tue, 21 July 2020 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E925B3A0A6E for <>; Tue, 21 Jul 2020 13:59:48 -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 P0hot04DcOL4 for <>; Tue, 21 Jul 2020 13:59:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 750C13A0A6D for <>; Tue, 21 Jul 2020 13:59:46 -0700 (PDT)
Received: by with SMTP id b9so10787177plx.6 for <>; Tue, 21 Jul 2020 13:59:46 -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=M+aMBFQIDIALP6IObYer7Yq/vCX4nsR/hepPJOi5zLI=; b=NGDJIWrpjwxJ6ESYULPuuC4YF6iBqn8heFHOglawcONlk5tou4RhEuSGzfcSNVmMzl 0sj1i2Iy/oXqqoWOKYrWFE3VUTf2r+694x4RAMAoiardXojY6B2bYRsZlpyOXiqADbD2 8SkRwqEDA4W2cQqfR6zVeNnMAF4OFb5GvndQU=
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=M+aMBFQIDIALP6IObYer7Yq/vCX4nsR/hepPJOi5zLI=; b=Lya400bh6SBjEONL2iUP1adFTOPqJSUPvl1PejN4UtxElZY5zTKqO1QkKmhAhEV4TD 8kOFCcqxbe31dKU46IervNng9L1zegudfLFWMLflWEnLUH+vxmmqNPDnUmpQr/tCtU4Z lwIzfbueEY6/XwRe4zuuqLaPfcvLszYqlYN17BT/dIFNNlZP1SbTaW83Y+AxeZ5DPLoQ jGuOQXxlcfJQHoFusjXceO/yqFxPz5g79pp10mm5tVW9RdeHcX3skNZieskWxcwG0xI4 qcmGyHwJ2fi7qPvwzh9hD9cz3UUHwtagIjpUa7SbxkEOmRfaAzXJAIfgQuXP4v9wofok 1QKQ==
X-Gm-Message-State: AOAM532TdLybbferkszSHTdRKYP55iFCugyKcQjJIMFbFBF96qfvWme0 /3uawTUD8XiBpqrdAFg4NDkv/96aNaUo+HnW5ayJ
X-Google-Smtp-Source: ABdhPJwB6EzNt+5mSYq4Z3c8gJWXRY80r57PqLfwpHPEltySX5Tt8fU6RRB1POX6HXuAwu4Ybd7S7IXhkYum1U72A5Y=
X-Received: by 2002:a17:90a:a78b:: with SMTP id f11mr6328601pjq.42.1595365185595; Tue, 21 Jul 2020 13:59:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 21 Jul 2020 16:59:29 -0400
Message-ID: <>
To: Victor Vasiliev <>
Cc: Lucas Pardue <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000002d00cf05aaf9e79c"
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 20:59:49 -0000

I guess you could have protocol-specific numbers and protocol-independent
syntax? Or you could allocate numbers in yet another number space for all
the existing settings. The latter seems like a lot of fuss, and the former
is kinda weird. At that point you may as well get a protocol-specific blob
(as in the draft) so the protocol library can reuse their preferred parsing

On Tue, Jul 21, 2020 at 4:22 PM Victor Vasiliev <> wrote:

> How would this work with regular SETTINGS?  HTTP/2 and HTTP/3 have
> disjoint setting number spaces, and it's unclear to me whether there's any
> significant overlap between those.
> On Tue, Jul 21, 2020 at 11:49 AM David Benjamin <>
> wrote:
>> On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue <>
>> wrote:
>>> 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.)
>> David