Re: Codepoint allocation for TLS extension

Martin Thomson <> Thu, 10 December 2020 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACD963A132D for <>; Thu, 10 Dec 2020 15:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=OOzS8tz/; dkim=pass (2048-bit key) header.b=JnoItJOq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YyloT4SPPX-w for <>; Thu, 10 Dec 2020 15:18:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D9F53A132C for <>; Thu, 10 Dec 2020 15:18:38 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id F03F65D8; Thu, 10 Dec 2020 18:18:35 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Thu, 10 Dec 2020 18:18:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=VKK2k/W2uowTfhg4jBFgbBcGEGyY ljkrRApsErSfZdo=; b=OOzS8tz/dvDalh42Rhuhj2Fnq2+PT6d8IMa5kdDBb5fH REcOq3JNANSuChG6HgA4Chq08cUsiWg2w6yF/DqwlV5WhP7RsSph9SuxrNgN2Jqn J1Tys+tK0la/kRHKnEn3S62aCQyT2B8wW6T57Pb72l8cMEn4mYCHHQASNtToASwc 5iWSqrrSdYY8UK+RYZ8UDGLIojXMobGZlrclRebVj2xsiAm2vXFVx4nHJrZNrlui inca4KiPny75rSBec/eNaa+6+3AfFTzJIGFWgSS6cEKXvy1vKAdgflbA5YN2O785 gRfpoG9uY0kkTFg914BWa0TYA6mUHX/CxTAtI7k4Cw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VKK2k/ W2uowTfhg4jBFgbBcGEGyYljkrRApsErSfZdo=; b=JnoItJOqEj86r7I1Rqv4CV jrT0NYALrGRQkOCKNkt/PQTfctuVxRYaidpDQmkzbBF7LfDIF4Ndonif2gO7fpuL 4GcpkzrJ6IHfDOSZ7VsPz3iQq/mec7U4v+AMgYg5wtSmEJsP33/mgbtT5L27yPu1 9fd83FEJb+eD7dUfV+7ViKoCjffohoC7+7eLGIl84Uo/HIHSAFSHM8zVbUW++phS +VkDhyRVPW67Exk+r08KiXpV+CupmEpcHvLFDtIxpcNby7Mr7NCRGOPbrrB361mw 2xX0bCFOe21UQn05GSNfT48JkZ2IV1tkyDjxurXLzb7e/Rete4OWk3TkepMhbDEA ==
X-ME-Sender: <xms:y6zSXw0WSdKSJmXMpLXWHOPi0qS5YBWtoD-pXi7sG1UcaTrQafwgXg> <xme:y6zSX7Et4BS7q4djWTk-dJPrOgZf5n85-4qYZtn6yh2oacVC5MS-SxqE9zqsolytb lcU9I9rQ0ctep0OsdE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekuddgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:y6zSX47SDOEwD0vjFm2-AuVMzjsj6jBq0k6ZQ_TjELSI-CbVuhguig> <xmx:y6zSX52mbNsIkA0QvsQ6chpJzum8pBrZeMinnAWwmWifL8gYOoZQlg> <xmx:y6zSXzHD8wWKiS2ywQ20ist0D_UBIDzYckAoUXoHN5Qwr0gh-zRF-w> <xmx:y6zSX5MIhXf1t-ONgIz7lyg8VnRqn-KdasW4COWI60VhMuSXgXEDXg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 04CDD2006A; Thu, 10 Dec 2020 18:18:35 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Fri, 11 Dec 2020 10:17:54 +1100
From: Martin Thomson <>
Cc: Magnus Westerlund <>, Lucas Pardue <>, Lars Eggert <>
Subject: Re: Codepoint allocation for TLS extension
Content-Type: text/plain
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Dec 2020 23:18:40 -0000

Just a follow-up.  IANA has provided a number (after one false start).  I've tested it, but I will ask that people test the changes in the upcoming -33 as soon as they are able.  I don't want there to be any mistakes.

*** Please don't deploy version 1 anywhere just yet. ***

Draft-29 (or later) is still perfectly good for interoperability testing and we'd like reserve the option to redefine what version 1 is for just a while longer.  If you deploy and we are forced to change something, you will spoil it for everyone.

Thanks to IANA, the TLS chairs and experts, our chairs, and Magnus for being responsive to this request.

On Tue, Dec 8, 2020, at 20:40, Martin Thomson wrote:
> Hi Everyone,
> I'm fairly sure that most people are deploying QUIC with the 
> quic_transport_parameters TLS extension using the 0xffa5 codepoint in 
> the current draft.
> Unfortunately, this can't stand.  That's a private use codepoint in 
> TLS.  The final version of QUIC will need a permanent allocation.  This 
> should be a problem in terms of collisions in the short term as QUIC 
> can't conflict with TCP use of TLS, but TLS expressly permits use of 
> this codepoint for private use, so we can't guarantee that TLS stacks 
> won't try to use this codepoint.
> I know that this is disruptive, and apologize for this not being clear 
> earlier.  It was originally, but a lot of time has passed since then 
> and I'm sure that many, like me, have forgotten this detail.  
> Hopefully this can be rectified without much fuss.  IANA has already 
> requested expert review for the allocation (I believe), so it might 
> just be a matter of getting the final allocation.
> Chairs, and AD, 
> Following the procedures in Section 3.1 of RFC 7120, this is my request 
> for early allocation of a codepoint, in case that is necessary.  I've 
> provided more context to those involved privately.
> I hope to have the final codepoints (version numbers, salt, retry keys, 
> transport parameter extension) in -33, which will go to the IESG for 
> approval in the next few weeks.
> --Martin