Re: [TLS] IANA Registry for TLS-Flags

[Eric Rescorla <[e-mail]>]

That's fine by me.


On Mon, Dec 13, 2021 at 6:31 AM Christopher Wood <[e-mail]>
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
>
> 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
> >
> >
> > On Sun, Dec 12, 2021 at 12:51 PM Yoav Nir <[e-mail]> wrote:
> >> 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 <[e-mail]> 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
> >>>
> >>> Please comment.
> >>>
> >>> Yoav
> >>>
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>