Re: Codepoint allocation for TLS extension

David Schinazi <dschinazi.ietf@gmail.com> Tue, 08 December 2020 16:31 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6D3A0FFD for <quic@ietfa.amsl.com>; Tue, 8 Dec 2020 08:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvjogegcEjmP for <quic@ietfa.amsl.com>; Tue, 8 Dec 2020 08:31:38 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AB03A0D82 for <quic@ietf.org>; Tue, 8 Dec 2020 08:31:38 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id o5so12619794pgm.10 for <quic@ietf.org>; Tue, 08 Dec 2020 08:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <4a606b9e-6dfa-44b7-9a11-626adb02c15a@www.fastmail.com>
In-Reply-To: <4a606b9e-6dfa-44b7-9a11-626adb02c15a@www.fastmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 08 Dec 2020 08:31:26 -0800
Message-ID: <CAPDSy+5wqkE=JAuA1EzrAvuSNNyzWqHGCs3=N9LoQ2mVLpBE9A@mail.gmail.com>
Subject: Re: Codepoint allocation for TLS extension
To: Martin Thomson <mt@lowentropy.net>
Cc: QUIC <quic@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Lars Eggert <lars@eggert.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000009d0b105b5f67a6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8EJZz75ouTdYaawSrn_5KO1c7Wk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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.

David

On Tue, Dec 8, 2020 at 1:41 AM Martin Thomson <mt@lowentropy.net> 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
>
>