Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

[Sean Turner <[e-mail]>]

> On Mar 12, 2018, at 22:46, Adam Roach <[e-mail]> wrote:
> 
> On 3/12/18 5:33 PM, Sean Turner wrote:
>> 
>>> On Mar 12, 2018, at 19:58, Adam Roach <[e-mail]> wrote:
>>> 
>>> On 3/7/18 12:58 PM, Eric Rescorla wrote:
>>>>>>  -  TLS SignatureScheme Registry: Values with the first byte in the
>>>>>>     range 0-253 (decimal) are assigned via Specification Required
>>>>>>     [RFC8126].  Values with the first byte 254 or 255 (decimal) are
>>>>>>     reserved for Private Use [RFC8126].  Values with the first byte in
>>>>>>     the range 0-6 or with the second byte in the range 0-3 that are
>>>>>>     not currently allocated are reserved for backwards compatibility.
>>>>> Unless I misunderstand the compatibility mechanisms here, the reservation of
>>>>> first byte=0-6 seems to assume that no further assignments will be made from
>>>>> the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the case, I
>>>>> would expect the IANA considerations section to include a request that the IANA
>>>>> close the table to further registrations. The same comment applies to TLS
>>>>> SignatureAlgorithm Registry.
>>>> Agreed, but I'd like to hear from the chairs.
>>> 
>>> I think we're still waiting to hear from the chairs on this topic.
>>> 
>>> /a
>> I think this got lost somewhere in the flurry of emails:
>> 
>> See s17 of https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>> We don’t close the registry because technically, if somebody really, really wanted to they could register values for earlier versions.
> 
> Ah, thanks for the pointer. I don't agree with your evaluation that draft-ietf-tls-iana-registry-updates preserves the ability to register values for earlier versions, as it marks all remaining available codepoints "reserved." That's effectively equivalent to what I'm asking for, though, so my comment is addressed.

Subtly different but I’m glad you’re good with this ;)

> There's still a potential mess brewing for the HashAlgorithm codepoints 224 though 253 colliding with SignatureScheme values of 0xE000 - 0xFDFF, but it seems pretty unlikely that SignatureScheme allocations will reach that point before 1.2 and previous versions disappear.

i may have been lazy when I just did 9-223.  We could obviously remove this by marking 224-253 reserved for both the HashAlgorithm and SignatureAlgorithm registries.  Note that there are also other unassigned values in 4-6 in SignatureAlgorithms and 7 in HashAlgorithm that should/could also be marked reserved.  But, we can do that on the IANA draft in early April.

spt