Re: [Tls-reg-review] Adopting tls-flags

[Yoav Nir <[e-mail]>]

You mean add the cross_sni_resumption value to the tlsflags draft?  Sure. We can do that, if we’re sure that the cross-sni-resumption draft is getting approved in this form.  I don’t think there has been a WGLC for it yet.

Also, section 4.1 of the TLSFLAGS draft has this advice:

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:

   o  Flags 0-7 are reserved for documents coming out of the TLS working
      group with a specific request to assign a low number.

   o  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.

   o  Flags 32-63 are for other documents, including experimental, that
      are likely to see significant adoption.

   o  Flags 64-79 are not to be allocated.  They are for reserved for
      private use.

   o  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.


So IMO this is more fitting to receive the number 8 rather than the number 1. That is, unless the WG wants to make the case that this flag extension is going to be present in most ClientHello messages from now on.

Yoav

> On 19 Mar 2021, at 22:38, Benjamin Kaduk <[e-mail]> wrote:
> 
> The draft that creates the registry owns the initial registry contents
> until the registry itself is created.
> 
> So, just put the value in the draft's source, and try to avoid re-using a
> number for different things during the draft's time as a draft.
> 
> -Ben
> 
> On Fri, Mar 19, 2021 at 01:26:10PM -0700, Christopher Wood wrote:
>> + tls-reg-review
>> 
>> Good question! Since this is a new registry, I don't see any problem with grabbing 1 to populate it. The registry experts may have a better answer though.
>> 
>> Best,
>> Chris
>> 
>> On Thu, Mar 18, 2021, at 5:06 PM, Victor Vasiliev wrote:
>>> Do I actually get to just use 1, or do I need to ask you to do the 
>>> early allocation process?
>>> 
>>> On Tue, Mar 16, 2021 at 9:50 PM Christopher Wood <[e-mail]> wrote:
>>>> Friendly bump!
>>>> 
>>>> On Mon, Mar 1, 2021, at 7:52 AM, Christopher Wood wrote:
>>>>> Hi Victor,
>>>>> 
>>>>> On Mon, Mar 1, 2021, at 7:39 AM, Victor Vasiliev wrote:
>>>>>> Hi Chris,
>>>>>> 
>>>>>> This makes sense.  I will update the draft some time after the upcoming 
>>>>>> IETF.  Do you want to just add a codepoint reserved for cross-domain 
>>>>>> resumption into the draft, or how does that work?
>>>>> 
>>>>> Good question. I suspect your draft would just add, in the IANA 
>>>>> considerations section, something like this:
>>>>> 
>>>>> ~~~
>>>>> This document requests that IANA create a new entry in "TLS Flags" 
>>>>> registry with the following parameters:
>>>>> 
>>>>> - Value: 1
>>>>> - Flag Name: "cross_sni_resumption" (or whatever you want to name it)
>>>>> - Message: NewSessionTicket
>>>>> - Recommended: Y
>>>>> - Reference: This document
>>>>> ~~~
>>>>> 
>>>>> (See https://tools.ietf.org/html/draft-ietf-tls-tlsflags-04#section-4)
>>>>> 
>>>>>> 
>>>>>> (sorry for late response, just noticed the part about the draft  submission deadline)
>>>>> 
>>>>> No problem!
>>>>> 
>>>>> Best,
>>>>> Chris
>>>>> 
>> 
>> _______________________________________________
>> tls-reg-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls-reg-review
> 
> _______________________________________________
> tls-reg-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls-reg-review