> On Mar 6, 2025, at 9:33 PM, Paul Wouters
> <paul.wouters=40aiven...@dmarc.ietf.org> 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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
