Re: [TLS] Application-Layer Protocol Settings

Lucas Pardue <> Tue, 21 July 2020 12:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7F4F3A07CB for <>; Tue, 21 Jul 2020 05:22:16 -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 Q1rs7PxLBFZK for <>; Tue, 21 Jul 2020 05:22:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F3C13A07CC for <>; Tue, 21 Jul 2020 05:22:15 -0700 (PDT)
Received: by with SMTP id s10so20939671wrw.12 for <>; Tue, 21 Jul 2020 05:22:14 -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=JUlZLoLzmGps33n98Tn7nSydkScfML1Z1ZSixyrR68g=; b=bSzIAaE/vK1gLm/jFMUpX2p+dFfRToBJUrKI+omvXFRp62BpYydsovjSNccAOZKsDR 76XCc8gJQRrX4livZfL1JRuSBineK8MLjzA2NeJYk+hbcDGI4si0D/NJZU2m6DaFrFm8 uFiAcxTBDxJEfXDL2AMx4s+p4vdMP66TeoSFkaHRiERBJGENr6Q1bhTD3kRHy9OXL5tu vaJONNRfud6yq2DuS9RNyi0x1dJ85XMgFcygkk0oWr/hUzieY2rytL8UTbKfhqyaebDV updmENotIl+jua2fYL5KC5lyfyGs8urldpi1HObWSSnEWMtFTlL6d0BSWWitGYqz1GTF QR4Q==
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=JUlZLoLzmGps33n98Tn7nSydkScfML1Z1ZSixyrR68g=; b=g1hJPcDByjJQkPsUtqs9tD51jviVi8RRemXbWUg9eD3AuM4ZbU315uhcrRJarku5Cv 02WqJspsUqiwv6Kc5/d1Yx9JGVfl0lDdfil1ZLXdfHtLc17IupAu2WYFQxrAqI8HxS85 cPB4le268bE/Bd4Bm6oGrTNgcc/w2VgaGbYHxtdAup4qOYQP1YwlL5qZWm0Ei9dXCW7t N24bKkVoUgLTBGrQ8RimEk2crtREq34m4lB3324cs2RavwznQFjiNEoO+n8037OUcC/7 Atz7taRPCabxcFeStaFs9cfR4mFeQW9ao3PqTGOVaLf5OX9WudRt+YZflWoxQuG5Q/T3 YaiQ==
X-Gm-Message-State: AOAM533EoeBIm5hEZzi0m8tocsHfb7GiyXJGdIxhBevf5CG4c4iRjAmX Wswt0417CdyuovfruJSYylwv4EftmWD5LGG/ua0=
X-Google-Smtp-Source: ABdhPJzwghNQSVsT9MASbFiAgmlSiEa+G7uX4y2WlOBBQ9QwYH6dZ85ZCm4Ghfrc8K2r/yHM/b9yiU7UKaOYtNnOId4=
X-Received: by 2002:adf:dcc9:: with SMTP id x9mr13017986wrm.153.1595334133536; Tue, 21 Jul 2020 05:22:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 21 Jul 2020 13:22:02 +0100
Message-ID: <>
To: David Benjamin <>
Cc: Victor Vasiliev <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000053dd0205aaf2acec"
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: Tue, 21 Jul 2020 12:22:17 -0000

On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <>

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