[TLS] Re: AD review draft-ietf-tls-rfc8447bis-10

[Sean Turner <[e-mail]>]

Okay PRs are ready to merge:
https://github.com/tlswg/rfc8447bis/pull/61
https://github.com/tlswg/rfc8447bis/pull/62

And I found some typos:
https://github.com/tlswg/rfc8447bis/pull/63

Will merge Sunday (when submission window re-opens) and spin a new version, unless you say otherwise.

spt

> On Mar 10, 2025, at 8:10 PM, Paul Wouters <[e-mail]> wrote:
> 
> 
> On Fri, Mar 7, 2025 at 12:52 PM Sean Turner <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On Mar 6, 2025, at 9:33 PM, Paul Wouters <paul.wouters=[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> AD review of draft-ietf-tls-rfc8447bis-10
>>> 
>>> I have some comments and small change requests. Do let me know if I got it wrong.
>> 
>> Will do.  BTW - one choice for you below.
>> 
>>> Section 3
>>> 
>>>         Setting a value to "Y" or "D" in the "Recommended" column requires
>>>         IETF Standards Action [RFC8126]. Any state transition to or from a
>>>         "Y" or "D" value requires IESG Approval.
>>>         
>>> Isn't this easier written as:
>>> 
>>>         Setting a value to "Y" or "D" in the "Recommended" column requires
>>>         IETF Standards Action [RFC8126] or IESG Approval.
>>> 
>>> This appears in a number of sections in the document.
>> 
>> This sentence structure appears in 10 places. The same types of sentences appear in 5 places in RFC 8447, but there is it "Y" and "N" not “Y" an "D". This I-D updates all of those 5 in RFC 8447, so sure we can make this change.
> 
> Great.
>>> Section 4 TLS ExtensionType Values
>>> 
>>>         Values with the first byte in the range 0-254 (decimal) are
>>>         assigned via Specification Required [RFC8126].  Values with the
>>>         first byte 255 (decimal) are reserved for Private Use [RFC8126].
>>> 
>>> I'd rather not let IANA figure out decimal network order byte math. Or
>>> require everyone to do that math when checking the registry. Why not:
>>> 
>>>         Values in the range 0-65279 are assigned via Specification Required
>>>         [RFC8126]. Values in the range 65280-65535 are reserved for Private
>>>         Use [RFC8126].
>>> 
>>> Also, this is not true for:
>>> 
>>>         65281   renegotiation_info
>>> 
>>> which is clearly not usable for Private Use. Maybe it makes sense to say:
>>> 
>>>         Values in the range 0-65279 are assigned via Specification Required
>>>         [RFC8126]. Values in the range 65280-65295 are Reserved. Values in
>>>         the range 65296-65535 are reserved for Private Use [RFC8126].
>>> 
>>> This then leaves 0xff00-0xff0f for whatever the reason for 65281 was to be
>>> able to happen a few more times, and keep the private range valid without
>>> strange exceptions.
>> 
>> I don’t think that has actually been much of a problem because it has been specified this way since RFC 4346.  So, we got two options:
>> 
>> 1) leave it alone
>> 2) drop the offending text because we are not changing anything WRT to the ranges in those 3 sections. If we do that I would suggest:
>> 
>> OLD:
>> 
>> *  Change the registration procedure to:
>> 
>>     Values with the first byte in the range 0-254 (decimal) are assigned
>>     via Specification Required [RFC8126].  Values with the first byte
>>     255 (decimal) are reserved for Private Use [RFC8126].  Setting a
>>     "Recommended" column value to "Y" or "D" requires Standards Action [RFC8126].
>>     Any state transition to or from a "Y" or "D" value requires
>>     IESG Approval.
>> 
>> NEW:
>> 
>>  *  Adjust the registration procedure related to setting the “Recommended” column as follows:
>> 
>>   Setting a value to "Y" or "D" in the "Recommended" column requires
>>   IETF Standards Action [RFC8126] or IESG Approval.
>> 
>> Which do you prefer?
> 
> I prefer 2)
>>> Section 6 TLS Supported Groups
>>> 
>>>         * Replace the registry range table note column for the 0-255,
>>>           512-65535 range with "Unallocated".
>>> 
>>> This makes no sense. That current line with its note reads:
>>> 
>>>         0-255, 512-65535        Specification Required  Elliptic curve groups
>>> 
>>> I understand that the note should remove the text "Elliptic curve groups",
>>> but it makes no sense to add "Unallocated" because the range does have
>>> allocations in it. Maybe just instruct IANA to remove the note "Elliptic
>>> curve groups" ?
>> 
>> I can get behind that.
> 
> Okay
>>> Section 11 TLS ClientCertificateTypes registry
>>> 
>>> The registry name is not "TLS ClientCertificateTypes" registry, but
>>> "TLS ClientCertificateTypes Identifiers" registry.
>> 
>> You are correct!
> 
> Good :)
> 
> Paul