Re: [TLS] Application-Layer Protocol Settings

Victor Vasiliev <> Tue, 21 July 2020 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FB0E3A0965 for <>; Tue, 21 Jul 2020 13:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.519
X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XFKZqifWo8AQ for <>; Tue, 21 Jul 2020 13:25:55 -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 BF9FD3A095F for <>; Tue, 21 Jul 2020 13:25:55 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxymu-0006GC-VM for; Tue, 21 Jul 2020 20:22:57 +0000
Resent-Date: Tue, 21 Jul 2020 20:22:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxymu-0006FZ-5H for; Tue, 21 Jul 2020 20:22:56 +0000
Received: from ([2a00:1450:4864:20::22a]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxyms-0007ME-3X for; Tue, 21 Jul 2020 20:22:55 +0000
Received: by with SMTP id f5so54523ljj.10 for <>; Tue, 21 Jul 2020 13:22:53 -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=Fz4avZOD/H4YZt9nH5xT7BsQX2Y0qIggwkhB+HfeGDA=; b=NWk/U5d1RpUqyskAjxJQhwfmXwNvehV9PMcGDhnI+px09XX9VO2DhzNA9rF021fybT Vt5dW6hfXMKvAQ+84V7UhaumwjOdxFeBSTOMwOp6aoWiTiRPwXL982ORe6cms8V+lzIU dyGJqXnByQ4V8qGYvoCJmqEYlG/tZZBTDZprTuifIgQTh5V2mgIUsHRcBKzarWLYUVhR X53EySwkQAZU9hGUd+ZYhBRAp0XNj9T1rytwD9+/8LK5i3mK6IjE1p62lczRPc1OT0Qp Nwbbl73URv+HzuTE+K+3ZCcgiy+KLRlArDW+bExfSBJQS1S4O0uDOMDtAqq/H5B+re4l UB4g==
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=Fz4avZOD/H4YZt9nH5xT7BsQX2Y0qIggwkhB+HfeGDA=; b=oT9j61+vJTFyBDD8l8JXbBCMbw8cUZsQj1t94gAs2UP0BwjKaUafAzfEz4B7NIZGQR vrJTYHIZ09bjUP5TzvfImmkiPl4O5KBl1lj+xo4E6XDTnMo5ITyVG1WjFHWgoMB02aHQ lJ0eadn53sy1Xv+0LYO29qLHaAjV+9i7YTlz6pj8xwU5/JVI1rfpr8iLKLVVH5FTdVRL nMIiay7vShQJtldRY7bPlPxPorOs3tde76IGUXozRQFJMzwzKw4FXgf9jSbcgNIKx1of HMhI0xxOGLU1cfxCY/zH9jy2fJsTVUMm1TnculNsiW6vJ3ClV4ihNOOxHrP6g2b3UBiB 5qwg==
X-Gm-Message-State: AOAM531o4DyqwfHp8hdI/31jEBv8uR7eJ6v830uNm4FiEu6rzaXsf9GJ DFXrFV9oVFXIuJNfEJ0phN+p8zycaBisLUL/zGUDtA==
X-Google-Smtp-Source: ABdhPJwvjfV/57Stz/lmQ27lviv1Zr4EmqOMK4j0HWghhlMKvu0xc0j/xCHO/GgUSOBrRc9TosF8bTaJb13AI2Rc1Uk=
X-Received: by 2002:a2e:9b87:: with SMTP id z7mr14524797lji.80.1595362962121; Tue, 21 Jul 2020 13:22:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Victor Vasiliev <>
Date: Tue, 21 Jul 2020 16:22:30 -0400
Message-ID: <>
To: David Benjamin <>
Cc: Lucas Pardue <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a5b76c05aaf96275"
Received-SPF: pass client-ip=2a00:1450:4864:20::22a;;
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jxyms-0007ME-3X 487575f273eabc2ce61eda8d9bc37d6d
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37905
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

> 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