Subject: [TLS] IANA Registry for TLS-Flags

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Dec 2021 23:21:30 +0200

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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Dec 2021 21:32:19 +0000

As one of the current designated experts, I’d rather there were almost no room for judgement or subjectivity in assignments.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 08 Dec 2021 09:39:41 +1100

On Wed, Dec 8, 2021, at 08:32, Salz, Rich wrote:
> As one of the current designated experts, I’d rather there were almost 
> no room for judgement or subjectivity in assignments.

This is part of why I think that Rich is an excellent choice of designated expert :)  Judgment is what we have the working group for.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Dec 2021 22:51:28 +0200

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 <[email-masked]> wrote:
> 
> Hi.
>

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 12 Dec 2021 15:56:56 -0500

There may still be benefit in allocating the private use block.  Otherwise
I think Martins text is sufficient.  Mike

On Sun, Dec 12, 2021 at 15:52 Yoav Nir <[email-masked]> wrote:

> 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)
>
> 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
>
> Please comment.
>
> Yoav
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Dec 2021 14:22:51 -0800

I'd probably reserve slightly more for standards action, maybe the first 24
bits. Otherwise, I agree with MT.

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 13 Dec 2021 06:31:06 -0800

How about we split the difference and go with the first 0-15 flags for standards action? We can keep the initial value of 8 for cross-sni-resumption since that document is going through the process. (We could also make it 7 or lower so we're not wasting an empty octet for this flag, should folks want to go that route.)

Any objections?

Best,
Chris

On Sun, Dec 12, 2021, at 2:22 PM, Eric Rescorla wrote:
> I'd probably reserve slightly more for standards action, maybe the 
> first 24 bits. Otherwise, I agree with MT.
>
> -Ekr
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Dec 2021 06:39:56 -0800

That's fine by me.

On Mon, Dec 13, 2021 at 6:31 AM Christopher Wood <[email-masked]>
wrote:

> How about we split the difference and go with the first 0-15 flags for
> standards action? We can keep the initial value of 8 for
> cross-sni-resumption since that document is going through the process. (We
> could also make it 7 or lower so we're not wasting an empty octet for this
> flag, should folks want to go that route.)
>
> Any objections?
>
> Best,
> Chris
>
> >>> 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)
> >>>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Dec 2021 14:47:13 +0000

>    How about we split the difference and go with the first 0-15 flags for standards action? We can keep the initial value of 8 for cross-sni-resumption since that document is going through the proc…

Works for me.

I think starting out with more than one flag byte is worthwhile, but I don't care much.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Dec 2021 06:19:19 +1100

>>    How about we split the difference and go with the first 0-15 flags for standards action? We can keep the initial value of 8 for cross-sni-resumption since that document is going through the pro…

Two bytes it is.  PR updated.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2021 22:59:44 +0200

So now that that is settled, publish a new draft?

> On 13 Dec 2021, at 21:19, Martin Thomson <[email-masked]> wrote:
> 
> 
>