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

[Sean Turner <[e-mail]>]

> On Mar 6, 2025, at 9:33 PM, Paul Wouters <paul.wouters=[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.

> 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?

> Section 5  TLS Cipher Suites Registry
> 
> This section contains some reasoning why it is Discouraging things. The current
> IANA registry also contains such reasoning on the form of notes, but this section
> does not add to the notes. So now this inforation is splintered between RFC and
> Registry. I think the easiest fix is to add these few reasons specified here
> as Note: to the IANA registry.
> 
> 
> Note that this registry states:
> 
>         When this registry is modified, the YANG module
>         "iana-tls-cipher-suite-algs" [iana-tls-cipher-suite-algs] must
>         be updated as defined in [RFC9645].
> 
> Has this happened or is it scheduled? If so who is the contact I can follow up with?

The YANG module is empty right now so I assume it needs to be scheduled. I assume IANA will run this as part of their IANA Actions process.  Confirming with Kent now.

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

> Section 11 TLS ClientCertificateTypes registry
> 
> The registry name is not "TLS ClientCertificateTypes" registry, but
> "TLS ClientCertificateTypes Identifiers" registry.

You are correct!

spt