Re: [TLS] Application-Layer Protocol Settings

Victor Vasiliev <> Mon, 20 July 2020 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 517F33A0E4C for <>; Mon, 20 Jul 2020 12:36:43 -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 I_nxROOSe8fB for <>; Mon, 20 Jul 2020 12:36:41 -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 B73903A0E4B for <>; Mon, 20 Jul 2020 12:36:41 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jxbXm-0002Qr-SS for; Mon, 20 Jul 2020 19:33:46 +0000
Resent-Date: Mon, 20 Jul 2020 19:33:46 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jxbXm-0002Q9-62 for; Mon, 20 Jul 2020 19:33:46 +0000
Received: from ([2a00:1450:4864:20::130]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jxbXk-0000Xz-Ju for; Mon, 20 Jul 2020 19:33:46 +0000
Received: by with SMTP id j21so10368310lfe.6 for <>; Mon, 20 Jul 2020 12:33:44 -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=b71hp2jkn2jo28HMWPKufvjTP9PwD+9zkzsQxvLKGes=; b=qmTXC+KcMs5UJ+2M6CzrHQ+/DpYyKFZYQjASR1cG/5vQUlejJof32PhUZBVfKwcn/N ks84YCWAvlGjXwqLrZB06/V+fb1hgh1n/Oux42VrA8vawWM2q8cTHX5PPFMszcIEmS/p biKciPS55igVDKGT+uKu6Ncwz6xxL0icgqsHdybaxMihhXzcRA2agxY5wjjRJFxfL/Au AWN+rlipI4XLyD6O72UKPmjSOsD0LwJ8fHOUmlx5MMBb/NmsdNL7iMygh3n+Vix3xLfe PZikyrASdgsfdNjbfToSJPRNdPLdXPcdhMTkCGGf7SkuEz6h2jgJummxbqCULMfZmXkm 6NQw==
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=b71hp2jkn2jo28HMWPKufvjTP9PwD+9zkzsQxvLKGes=; b=QmIk4KqVEwO8GLP7j7We5hg3GSBFO4HfX2Kvaun6WqTGC5HvgO+y1RyT1azBKRo2+a 4avG8stElduUGpNz5OtT3ZRAaXaBEu89LKFecvnj2PvtIj5RPzaLK7DDUTMUk9C5VmZC i65sf3T/TvuhTQJ7DNjIMoul3mpVM1XjooSWI6ay9Sg4sknw0CK+zOaNAh5uwHSZr9J7 UKq/iGllOc6h4LJ6L9gcxmTrIPOi8QyBTQnEO+dztw9lTuLbPOpUwvx4g1u0UPt5lGY4 ZjYL53SHq8G48biMKITaeOwpOGyM63aBMVLHFgSBLJTW+xNw8zjQteBa+H6wKy5Ca/1W 9Hhw==
X-Gm-Message-State: AOAM5322RYPQ7OEQn5fuXTFeEOWPTnCQdfWYaTshMNijs1TYqQ+Sc/vO yckPvTyAR4iADp6q/q4EodhWRcm3MLjQw4TA+PQUiA==
X-Google-Smtp-Source: ABdhPJxPgl0Zbq9hbHJN1x1Q4mAFgKRfQ23QKmlqVYWw7qrVy8eqOlCWP92+KfEuXhNmOVCchNNz7B00rsZezyUL2UQ=
X-Received: by 2002:ac2:5338:: with SMTP id f24mr1185249lfh.5.1595273612577; Mon, 20 Jul 2020 12:33:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Victor Vasiliev <>
Date: Mon, 20 Jul 2020 15:33:21 -0400
Message-ID: <>
To: Lucas Pardue <>
Cc: "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000000e5705aae495e9"
Received-SPF: pass client-ip=2a00:1450:4864:20::130;;
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: 1jxbXk-0000Xz-Ju 09c4bfb0aa06b2ff8f32844d67cd56d7
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37894
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <>

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

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