Re: [TLS] IANA Registry for TLS-Flags
So now that that is settled, publish a new draft? > On 13 Dec 2021, at 21:19, Martin Thomson wrote: > > > > On Tue, Dec 14, 2021, at 01:47, Salz, Rich 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.) >> >> Works for me. > > Two bytes it is. PR updated. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Registry for TLS-Flags
On Tue, Dec 14, 2021, at 01:47, Salz, Rich 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.) > > Works for me. Two bytes it is. PR updated. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Registry for TLS-Flags
>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.) Works for me. I think starting out with more than one flag byte is worthwhile, but I don't care much. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Registry for TLS-Flags
That's fine by me. On Mon, Dec 13, 2021 at 6:31 AM Christopher Wood 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 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 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 > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] IANA Registry for TLS-Flags
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 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 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
