Re: [TLS] IANA Registry for TLS-Flags

Yoav Nir <ynir.ietf@gmail.com> Sun, 12 December 2021 20:51 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A663A0B44 for <tls@ietfa.amsl.com>; Sun, 12 Dec 2021 12:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 tIE0wlvnBkM3 for <tls@ietfa.amsl.com>; Sun, 12 Dec 2021 12:51:34 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4FDB63A0B3F for <tls@ietf.org>; Sun, 12 Dec 2021 12:51:34 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id t9so23952067wrx.7 for <tls@ietf.org>; Sun, 12 Dec 2021 12:51:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=blck894/0KrybH9cF50px7nIsIvaJ8xAPUVSh76wfgY=; b=P4HtbU/LoP8De/bvV0nxZVoG+//Wy6AuyNINFQlSEBz748yaPMtUhJ3aMjt+Bree/l ypexMrsrdUqPQRiGDks6EpzZP9Y9xcPJpOZj3F0seWDmXp2npuMyWbi7tspuTa0VXjtR kT1k8Ox3QudmTw+STmzBXCVcxtNgNZ0bzMPktXbJ/kq43OQkHT9YN7NbqN7+zLTQx/xz MdaCQym1/CBFdwH8Ppjg4FHI4L5GqGuP/fYm3TkTE+cZczWkuzvH1n0wjoOus1nyAXKF 5Yl/yQHnxAc1repRge7iIf2i5+g1ZkVriCcf0y5WPFx52GJ7CvnJ5elmoPg55/ViGmnZ oDIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=blck894/0KrybH9cF50px7nIsIvaJ8xAPUVSh76wfgY=; b=3rQSf5zPAlDNkyXIlixjaUdun7HGDb7gou+gF34GaJWbdwhxupWl9Co8XIoz1umtnF x10Q6Oyo/nYZJTZhpfZYCfwKxE8ZVd3/vqJoghOwOZj54upLx4Byh0CS06JSW9pbcpHG dajesG7Yy+/9SX7R2KbiP1qc7yeQqrpLoJd13c15lghDevj1rW7von1neRFwvKIAQQ3/ aW2ul2c81PRNIVo7qMsay1YBZspSkeTcMdKaTDHUMbGIMsk4x+tUNe9P1sdDfS6LYZNn Fpo2kFE1kyDIlC3EBFAFfJDynViwWkYZQZNw7Ueo3XL0a+9KQak0oXMTPxdhf5sfbKLF KOsQ==
X-Gm-Message-State: AOAM5320MKc9VgD+inHS1xotuCrZ5p+4JKKtK81Dnb/wGGKA5s2Vj5Au 6l86wOuTn8TG853qsQA17/V6fKFNFJaFmA==
X-Google-Smtp-Source: ABdhPJy60iwxHXM0yd6ccnUxqPTO2mazDbM/IS6U1+z+VRJ4aUBrPXfzkesaDhieK0CgW3lnicvTSQ==
X-Received: by 2002:adf:9004:: with SMTP id h4mr11337683wrh.593.1639342291125; Sun, 12 Dec 2021 12:51:31 -0800 (PST)
Received: from smtpclient.apple ([87.69.209.176]) by smtp.gmail.com with ESMTPSA id q8sm8681095wrx.71.2021.12.12.12.51.29 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Dec 2021 12:51:30 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A0861619-B4E7-4D6F-96AA-623B9B20A519"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
Date: Sun, 12 Dec 2021 22:51:28 +0200
References: <A3B1B532-912A-4135-BCC8-6F48A9AE2C4D@gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <A3B1B532-912A-4135-BCC8-6F48A9AE2C4D@gmail.com>
Message-Id: <789BD7B9-F369-4DB8-95E3-89FAEC7F6D51@gmail.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/c725ApHUrTkMOCm34uj6hIOnwBE>
Subject: Re: [TLS] IANA Registry for TLS-Flags
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Dec 2021 20:51:37 -0000

Well, that’s two voices for Martin’s PR and just me liking the convoluted text that I wrote.

Chairs, care to call consensus?

Yoav

> On 7 Dec 2021, at 23:21, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> Hi.
> 
> We have one outstanding issue about the TLS-Flags draft. It’s about the IANA registry. The way the extension is defined, low identifiers for flags result in shorter extension encoding. For this reason, we want the most popular flags to have low numbers. This is especially true for flags that everyone will use (think RI)
> 
> So the current text says this:
> 
> 4.1.  Guidance for IANA Experts
> 
>    This extension allows up to 2040 flags.  However, they are not all
>    the same, because the length of the extension is determined by the
>    highest set bit.
> 
>    We would like to allocate the flags in such a way that the typical
>    extension is as short as possible.  The scenario we want to guard
>    against is that in a few years some extension is defined that all
>    implementations need to support and that is assigned a high number
>    because all of the lower numbers have already been allocated.  An
>    example of such an extension is the Renegotiation Indication
>    Extension defined in [RFC5746].
> 
>    For this reason, the IANA experts should allocate the flags as
>    follows:
> 
>    *  Flags 0-7 are reserved for documents coming out of the TLS working
>       group with a specific request to assign a low number.
> 
>    *  Flags 8-31 are for standards-track documents that the experts
>       believe will see wide adoption among either all users of TLS or a
>       significant group of TLS users.  For example, an extension that
>       will be used by all web clients or all smart objects.  The only
>       entry in the initial registry is from this range.
> 
>    *  Flags 32-63 are for other documents, including experimental, that
>       are likely to see significant adoption.
> 
>    *  Flags 64-79 are not to be allocated.  They are for reserved for
>       private use.
> 
>    *  Flags 80-2039 can be used for temporary allocation in experiments,
>       for flags that are likely to see use only in very specific
>       environments, for national and corporate extensions, and as
>       overflow, in case one of the previous categories has been
>       exhausted.
> 
> 
> Quite verbose. Martin Thomson suggests a shorter version that only reserves flags 0-7 for standards action and leaves everything else for “specification required”. No reservation for special request. No private use reserve. No experimental or judgment based on the likelihood of wide adoption:
> 
> https://github.com/tlswg/tls-flags/pull/14/files <https://github.com/tlswg/tls-flags/pull/14/files>
> 
> Please comment.
> 
> Yoav
>