Re: [TLS] Application-Layer Protocol Settings

David Benjamin <> Tue, 21 July 2020 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 470A13A0A6E for <>; Tue, 21 Jul 2020 14:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.019
X-Spam-Status: No, score=-3.019 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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qEsXfozMhmz6 for <>; Tue, 21 Jul 2020 14:03:05 -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 54A073A0A6D for <>; Tue, 21 Jul 2020 14:03:05 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxzMm-0004Pg-9c for; Tue, 21 Jul 2020 21:00:00 +0000
Resent-Date: Tue, 21 Jul 2020 21:00:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxzMl-0004Ov-87 for; Tue, 21 Jul 2020 20:59:59 +0000
Received: from ([2607:f8b0:4864:20::1029]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxzMj-00034Z-7c for; Tue, 21 Jul 2020 20:59:59 +0000
Received: by with SMTP id cv18so1888794pjb.1 for <>; Tue, 21 Jul 2020 13:59:56 -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=GqqOdiV/KWKbqwSgtXFHbcWPf9GYgsYg8K71JlLly1e1BCkhrzzGaEDRmQ20Bknnjf dVbPIYHVMcjUfFUcCw0WO08EN9tDF7QGyFfIphv+JK8qoPsbOe0dDShJUUzhjzfSgDL0 Mcmm7qGhS3W1RJy1w6O0+Kw3XDMp7PJpGwKSHw/hkgIxVOJ1Nllx/kFNkuF8EFJdzzKJ uHBcDVDD4otzGXu09pStB1uTXBqXF6Qh6hG6zYV0dyE7EzYTQY73StnygXpOZtk4PsMY Rw4FPMZ/GGVSS9QjpjhjoeuhqWbt4sDHdBEL7N1o0Z4UqyLtTaCL3NKkD3tfl1RiZOMr T43Q==
X-Gm-Message-State: AOAM5309JH8ocfU1byBIFhFz/8vmIjBSp9afw4Bx5tSj/xzILfQJN9EI DF/sxSqHtux5iGFhdGA79PxjpLzT3I8/gHHXQ4wx
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"
Received-SPF: pass client-ip=2607:f8b0:4864:20::1029;;
X-W3C-Hub-Spam-Status: No, score=-11.5
X-W3C-Scan-Sig: 1jxzMj-00034Z-7c fd359f64b51d9ccae8502a74166a36e3
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37906
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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