Re: [TLS] Application-Layer Protocol Settings

David Benjamin <> Mon, 20 July 2020 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F6413A0EB5 for <>; Mon, 20 Jul 2020 13:42:09 -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 4scQvf7dJ3rx for <>; Mon, 20 Jul 2020 13:42:07 -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 B24813A0EB3 for <>; Mon, 20 Jul 2020 13:42:07 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxcZ0-0006bA-Cz for; Mon, 20 Jul 2020 20:39:06 +0000
Resent-Date: Mon, 20 Jul 2020 20:39:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxcYy-0006aP-Mx for; Mon, 20 Jul 2020 20:39:04 +0000
Received: from ([2607:f8b0:4864:20::52f]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxcYw-0002ka-KC for; Mon, 20 Jul 2020 20:39:04 +0000
Received: by with SMTP id t6so10882360pgq.1 for <>; Mon, 20 Jul 2020 13:39:02 -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=X5+2ARQwyufLKQvrjJ7PfgYRTUTNxwEZF45o7qd7ANI=; b=ifRGIPHhon3AkICIu9h1C25BOOOV6VuogkB104x8fjgP6R8DmW511+t7WwUXKhLRsJ 9MSkWd/xxEn/lsAXVGO/wMEh5q3c7aYwtLjQOS+GcYtfRBVwFySFz0sxusKaFGR2wISG B1LC8hb4L8OrPHbHJCb6aNbK2iti9yylhirzo=
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=X5+2ARQwyufLKQvrjJ7PfgYRTUTNxwEZF45o7qd7ANI=; b=Tnx0QzwyZF9FNA7QwvwHEPKsF0mKG+cOR1vjB1PUXptb9QcJwNLfdxFV4DJ0TWi4ja sI6WFyqzvPbsDFcDRN4I6JIBYJ8rtBcLO08C5XTGVHGqV/aaGQT2EL4rexH1OxW+GMAp cpOQjeJTKTl26c7uu8Q4PaU3GIxuzvRSxtMnnNFGpOBTmSxVf4lEAGxq9+5EvuScJOQP XCTSXzFhdkEgNwLxxuIIIV7HNln2B2YmucYLLlTpfnjov+92i61pCvr7Seotq+WIt6ds iUqou8ZzRJ8Apjzk5WkcxWfUqO56TcOOCqCCjQEg2qLIXz1mOtV7udrRPsUFCAP60SBX bLEA==
X-Gm-Message-State: AOAM533a5EHy0gYc6Gbf3t9AUcaN3T+A/QbmT5Kgv706XQIp6ndBrh/S sIq3E0eJW9J7fpcjNhQQkaMryWzGdFoLdvembuWR
X-Google-Smtp-Source: ABdhPJymyhn+iECZwYq2yFw8EtmtxLIJC/IgI7jYE83uYyW447EAFPWIIELFyVM04aHvf+y957LECITrcMmrtV45jhU=
X-Received: by 2002:aa7:8507:: with SMTP id v7mr21071118pfn.218.1595277530970; Mon, 20 Jul 2020 13:38:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 20 Jul 2020 16:38:34 -0400
Message-ID: <>
To: Victor Vasiliev <>
Cc: Lucas Pardue <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000008da9ad05aae57e33"
Received-SPF: pass client-ip=2607:f8b0:4864:20::52f;;
X-W3C-Hub-Spam-Status: No, score=-11.5
X-W3C-Scan-Sig: 1jxcYw-0002ka-KC 991f22a58d965d76997cb52f388d10e4
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37895
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv=> wrote:

> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <>
> wrote:
>> Hi Victor,
>> It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in
>> your original email. I was reading it in the context of David Benjamin's
>> thread on Client Hint Reliability [2]. There's a couple of things that
>> surprised me when reading both drafts:
>> 1. ALPS in HTTPS actually supports more than just exchanging Settings
>> Parameters, it can actually hold a series of frames. It's just that ALPS
>> only defines SETTINGS to be allowed, and Client Hints Reliability wants to
>> add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the
>> idea of supporting any old frame in the TLS handshake, SETTINGS are at
>> least reasoned about in terms of how they are remembered for the purposes
>> of 0-RTT.
> It explicitly bans all existing frames that are not SETTINGS.  The problem
> here is that SETTINGS only supports integral values, so we'd be limited to
> those if we make ALPS just SETTINGS.

Right, concretely there is an "Allowed in ALPS" column added by Victor's
ALPS document, which my document sets for the new frame. Old frames weren't
designed with ALPS in mind, so the ALPS document needs to make a decision.
New frames can reason about the implications of opting into ALPS and do so.

As Victor notes, it's only a new frame because we got SETTINGS values wrong
and, per earlier discussion, the extension point we currently have is new
frames. If we want something even more restrictive, we could instead
revive draft-bishop-httpbis-extended-settings, say only SETTINGS and
EXTENDED_SETTINGS are allowed, and close it there. But I think the new
column works fine and matches how this sort of thing usually works.

> 2. ALPS in HTTPS makes it mandatory to support some settings to disable
>> static and Huffman header compression. That seems pretty onerous. If there
>> was interest in prototyping something like ACCEPT_CH-in-handhsake it
>> requires a modification of a QPACK dependency. On the other hand, if you
>> don't make these settings mandatory, then you won't achieve your objective
>> of removing the mandatory parts of HPACK/QPACK. To me this is a signal that
>> ALPN is a better option to negotiate a profile of H2/H3 that modifies
>> mandatory compression behaviour.
> That's a fair point.  I think I have an idea of how to split those
> settings into a separate draft without resorting to a new ALPN token.
>> Cheers
>> Lucas
>> [1]
>> [2]
>> _______________________________________________
> TLS mailing list