Re: [TLS] Application-Layer Protocol Settings

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29BC73A0B3F for <>; Tue, 21 Jul 2020 08:51:58 -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 awobuA7u-Osz for <>; Tue, 21 Jul 2020 08:51:56 -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 7B8F43A0B3E for <>; Tue, 21 Jul 2020 08:51:56 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxuWG-0007Yw-Ug for; Tue, 21 Jul 2020 15:49:29 +0000
Resent-Date: Tue, 21 Jul 2020 15:49:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxuWD-0007Y7-8W for; Tue, 21 Jul 2020 15:49:25 +0000
Received: from ([2607:f8b0:4864:20::42a]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxuWB-0005s7-A0 for; Tue, 21 Jul 2020 15:49:25 +0000
Received: by with SMTP id q17so10907206pfu.8 for <>; Tue, 21 Jul 2020 08:49:22 -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=VuraCS3sCJo0pKL2Nay98CmAj6WG6KxG9dILtqmEippG4rJqaZLCfTEva/W7VtH47H eBtJ8cbwh2icDwpzCdv+kslFMx79Rdj3GA2c8TRCfAFePE/qo39NGZqBhCZcFm7jAJ6n Qg3PNXuuj8gMDYRVM/5nMpc7Vi4bltrspWihwtiBdDU3vpGArTYsw1nGosk8LXIqpFzg RBDvlOYU37wlZWVLPxPB1H7E8dYPovyBnrGQ15A0GpVfCDqD9LM0PTQxUCPF2ruKnZsE 7bxdVUjI/Jk1sngpYYOVQKcS+vHYBNnI+LxuOYUVyDRI9GqzJft/QdSR0vaersaQyi5u +51g==
X-Gm-Message-State: AOAM533mgAlPNraRbJjJLNpM+GvBliFY57+xC+Rnnrq3wh62KzXGLxsE CBWBu9pzHZZxjuiKl4oKUd6KYt4unKy3lE4AOYZl
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"
Received-SPF: pass client-ip=2607:f8b0:4864:20::42a;;
X-W3C-Hub-Spam-Status: No, score=-11.5
X-W3C-Scan-Sig: 1jxuWB-0005s7-A0 454d15aac6893a07cadc6cf62eaf1a60
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37899
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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