Re: Codepoint allocation for TLS extension

David Schinazi <> Tue, 08 December 2020 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2D6D3A0FFD for <>; Tue, 8 Dec 2020 08:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_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 yvjogegcEjmP for <>; Tue, 8 Dec 2020 08:31:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44AB03A0D82 for <>; Tue, 8 Dec 2020 08:31:38 -0800 (PST)
Received: by with SMTP id o5so12619794pgm.10 for <>; Tue, 08 Dec 2020 08:31:38 -0800 (PST)
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=sa64YiNKU78QL4I50YBrmS5vTDajo9poPRlWgI5jmJg=; b=liPP5qrUqnw+TDUmb18rnoreI+2hTXTZP3rxasOozpnaAxNQOF7r57w1j7bq3dCMLu 8vae/gqxFHp1GZTaZD33nTBqtYcyRRClYr774d1o1EFfgi29U8Z1eCZP3gLRd3GmhYKH ptsLRJHWVR3iEDtBRXv8NwHDFsbi4GgzLxadI9tlTYWITNHLRwFQ0LmOEm05ORVsCRsi CcUOzU66KWkBkOYk6ORDyu0F7HWJSGHkxVdHHr00hJJnKQbrU6NHq1UVX5MWwTm002Me 0aa8+li8BPkTMkVUwROhazyYuJLujCswQgkZKxKpg0/rQoD5S/9VR/60rSJIsnG9zzgj 7o3Q==
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=sa64YiNKU78QL4I50YBrmS5vTDajo9poPRlWgI5jmJg=; b=CGtc9YaZUN/+FRpr7/USOg//FEsYrtUNsjAuAlFLg3keCVAnFI9sbmhDZ5eH9uCzxc eKwkCovjdaC4K+Y9vxq5gfUT7ixr9hTGJaTrdjIj37D6DeBHxquT2HyBRI4ygx4kYkGr ZYnqnG7LYs3SrhCbNxny2Ga9XlfZUmcXlueGUCjcirG6YR0zUi3gKtuB9hUEMHKqoYmT 2ZsGmqyqX2gpdoLp2zI6JuN5hxZLMjOJAjh9KYGr31Wxmd3y6VZiGdM4QiXJg76m9QVB m6Fuaxr7TY9SGGiy18Db+1je4sNS54guYitFaMMg3xYjzwlnrQxVogI8Kb0c8C0E6GT8 zWpA==
X-Gm-Message-State: AOAM532E6EhJeRZNLXPg7dY5Rz8dvRESz0FvW2TA0vJlYLxNp9QhKX7R VuKNMg5xzxg0r5fl4A1UwnGO3eQXb9efvrdD0MU=
X-Google-Smtp-Source: ABdhPJxr7WxHJoHh1buGEvSSOpoVsmw6OgAUb6rm3zNx5Xn0G2mxyKoceMJ6gyEvmsgymGVQ4aCYBCX18tIjLE7LOoU=
X-Received: by 2002:a63:b1c:: with SMTP id 28mr23372775pgl.206.1607445097598; Tue, 08 Dec 2020 08:31:37 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 08 Dec 2020 08:31:26 -0800
Message-ID: <>
Subject: Re: Codepoint allocation for TLS extension
To: Martin Thomson <>
Cc: QUIC <>, Magnus Westerlund <>, Lars Eggert <>, Lucas Pardue <>
Content-Type: multipart/alternative; boundary="00000000000009d0b105b5f67a6c"
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: Tue, 08 Dec 2020 16:31:40 -0000

Ah that is unfortunate, but I agree that we should fix it.
>From Google's perspective, I think we'll keep the old
TLS codepoint in h3-29, and switch to the new one when
we ship the QUIC RFC version.


On Tue, Dec 8, 2020 at 1:41 AM 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