Re: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Sean Turner <[e-mail]>]

On Apr 3, 2018, at 23:09, Adam Roach <[e-mail]> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-tls-iana-registry-updates-04: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the work everyone put in on this document. I have a handful of
> comments, ranging from nits to minor issues. They appear in document order.
> 
> ---------------------------------------------------------------------------
> 
> Title:
> 
> Please expand "TLS" and "DTLS" in the title. See
> https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

Sure, but I have also just sent a request off to get TLS and DTLS added as well-known abbreviations so I’m hoping to change it back during AUTH48 ;)

> ---------------------------------------------------------------------------
> 
> Abstract:
> 
> Please include the list of updated RFCs in the abstract. See
> <https://www.ietf.org/standards/ids/checklist/> §3.1.D. The current formulation
> of "This document updates many (D)TLS RFCs (see updates header)" is problematic
> due to the factors described in the final paragraph of RFC 7322 §4.3.

See Ben’s response.

> ---------------------------------------------------------------------------
> 
> §2:
> 
>> Instead of listing the changes and their rationale in this,
>> the introductory, section each section provides rationale for the
>> proposed change(s).
> 
> There's something awkward with the commas here. Perhaps you mean:
> 
>> Instead of listing the changes and their rationale in this,
>> the introductory section, each section provides rationale for the
>> proposed change(s).

Yep that does read better.

> ---------------------------------------------------------------------------
> 
> §8:
> 
> This section doesn't indicate anything about the disposition of
> "token_binding," which is due to (potentially) expire in 11 months. Given that
> the temporary property of this registration is due only to the previous policy
> that this document is obsoleting, it seems that this document should instruct
> IANA to remove the temporary status from the "token_binding" TLS ExtensionType.

I think that would be terribly unfair especially since the draft defining the token_binding extension is on the 5/10 telechat ;)
https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/
How about I just get them to add a Recommended = Yes column.

> ---------------------------------------------------------------------------
> 
> §8:
> 
> The table that adds a "Recommended" column to the TLS ExtensionType does not
> indicate values for "token_binding" or "cached_info." I suggest either adding
> them, or adding text to explain their omission.

Can’t believe I forgot cached_info.   I’ll add a note about token_binding.  I also just sent the WG a note about needing to add the Recommended “Yes” value to their IANA considerations.

> ---------------------------------------------------------------------------
> 
> §9:
> 
>> assigned via Specification Required {{RFC8126}}.  Values with the
>> first byte 255 (decimal) are reserved for Private Use {{RFC8126}}.
> 
> Nit: the "{{...}}" citation style is probably not what you intended.

Ah it did that because it’s a code snipet :(. Fixed the multiple occurrences.

> ---------------------------------------------------------------------------
> 
> §13:
> 
>> o  A "Recommended" column to the TLS Exporter Label registry.  The
>>    table that follows has been generated by marking Standards Track
>>    RFCs as "Yes" and all others as "No".
> 
> No rows are marked "No." Presumably, the text above should instead say "any
> values not indicated in the table below [will be/have been] marked 'No’"

yeah I think it’s that the others are "to be marked” (same for the cipher suites).

> ---------------------------------------------------------------------------
> 
> §14:
> 
>> 120   no_application_protocol  Y  [RFC7301]
> 
> Every other updated table is amended to also point to this document. I presume
> that omitting it from this entry is an oversight, and that it should instead be:
> 
>> 120   no_application_protocol  Y  [RFC7301] [RFCthis]

Yep.

See the following PR to address the above changes:

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/71

> ---------------------------------------------------------------------------
> 
> §17:
> 
>> o  [SHALL update/has updated] the TLS HashAlgorithm Registry to list
>>    values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
>>    to list values 4-223 as "Reserved".
> 
> HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and 8.
> Presumably the reserved ranges should be "7 and 9-223" and "4-6 and 9-223",
> respectively.

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65

> ---------------------------------------------------------------------------
> 
> §17:
> 
>> Despite the fact that the HashAlgorithm and SignatureAlgorithm
>> registries are orphaned, it is still import to warn implementers of
> 
> nit: "important"
> 
>> pre-TLS1.3 implementations about the dangers of blinding implementing
> 
> nit: “blindly"

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/70