Re: [TLS] Application-Layer Protocol Settings

Lucas Pardue <> Mon, 20 July 2020 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9DC73A0E0C for <>; Mon, 20 Jul 2020 12:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2kt7ic902aGo for <>; Mon, 20 Jul 2020 12:10:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F68F3A0E4A for <>; Mon, 20 Jul 2020 12:10:32 -0700 (PDT)
Received: by with SMTP id 184so585236wmb.0 for <>; Mon, 20 Jul 2020 12:10:32 -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=++97zvIBZkL7n9HJE9z7TuaAjo0jb6dWgbjarMJUHu0=; b=LuF2jZvmIZ84EPfSHQC3/p49PPx4di5p8FiC371JK8OGF3V3iPLE9NhPbeiynAAnOk 3YyiljJIBhapFJ9RiUdGjN57JHPSR+qAhQUqv9TqKzK3AxhWZBG4T85z6NjHh+3nl1K0 gFCYPQliRdaux2RUyc1F1UM5LD9IY3YSa7B25GvwWlCP/AEIrT7eOS4bbAFnti4Qp0q3 O8IS5i6EAYPCW4M4F45CCbZlAXQculokvHBqJaLg6Zexhhu/TC4ASOJZz/uH227u43Vk AAnYrTx42c3fQVvif+fTU5G9c9auc4pMqZEYDn/U+LIDUf6jgiRkJaM6E3LNNuhw3//I 6Sow==
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=++97zvIBZkL7n9HJE9z7TuaAjo0jb6dWgbjarMJUHu0=; b=joD6QXf9uJz8reNVntTfGCLWEyQqsqJ3CECkvkJ/WZsrwm8fY7iCTFVsZkreQ7Dffi S6xJDCwsxbKDFYsptlg/prK85XTFE1TsJrzS6+O7hZYmzd+xlo6ecRt1LV0GF5LHQ+tD NYnrm8mKc1AodJpohE8ttx3enpX+nk59yD1gkik7tRFvZPZQTcXkOytFTjOaVnDyH07a gYZKuT1a1ms5jwpwrp1pE4jLnfqYEsjrY7rVkmKu9VFCX5OSQUUpv+wLF0Sa4DGEIzjs afxOQu3sKqQS/w+jM9mscG8zbq7+DXCcZdXdGFnOIZT33Bx1H3yxswHDrRg+IBI2HbM9 sMBQ==
X-Gm-Message-State: AOAM532Ce8dKNr85qVSoTGZzFsZ6AUmos33AG4T+w2a49e78OO/Th4yb FS/iEZEd55wxQmzMIr2m1NyLAvtMBqNqvn7YAwU=
X-Google-Smtp-Source: ABdhPJzOjXJLiWjHS0IhykqP3wPwuEW/m18LfLRcJv6jCEQ2IuLe0t5yRoNaHSor7X33lEG4KcXJ0JE/A4s2Hwm+NPs=
X-Received: by 2002:a1c:2dc6:: with SMTP id t189mr746180wmt.26.1595272230599; Mon, 20 Jul 2020 12:10:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Mon, 20 Jul 2020 20:10:19 +0100
Message-ID: <>
To: Victor Vasiliev <>
Cc: "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a0018b05aae44286"
Archived-At: <>
Subject: Re: [TLS] Application-Layer Protocol Settings
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2020 19:10:38 -0000

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