Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-rfc8447bis-12: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Joe and Sean, Thank you for the effort put into this specification. This maintenance effort is really important from an OPS standpoint. As rightfully discussed in the spec, the registry may “lag behind the most recent advances in cryptanalysis”, but that risk can’t be nullified especially given the process time to transition some values. Thanks to Giuseppe Fioccola for the OPSDIR review and for the authors for engaging and converging. Please find below some comments: # Meta comment I understand this is an update not a bis, but the discussion in the write-up confuses me a bit. # Updates Duplication/Updates Inheritance We have the following: CURRENT: Updates: 3749, 5077, 4680, 5246, 5705, 5878, S. Turner 6520, 7301, 8447 (if approved) sn3rd … This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. Except the mention of 8447 (which is justified), all other entries were already updated by 8447. Unless there are new updates in this new iteration (which I fail to tag), the other updates are already anchored in 8447 and do not to be repeated here. Did I miss something here? # TLS registries CURRENT: This document instructs IANA to make changes to a number of the IANA registries I suggest to add pointers to these registries. This is even important, especially that the IANA registries are authoritative in this context. I had to search for those when reviewing the document. Having readily-available pointers (not only here, but also when discussing individual registries) is convenient for readers, especially that these are not in the same location, e.g., * https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml BTW, we may explicit this is about TLS registries. OLD: This document instructs IANA to make changes to a number of the IANA registries NEW: This document instructs IANA to make changes to a number of IANA TLS registries .. # Section 1: IANA Note CURRENT: | NOTE for IANA: This document specifies changes to the registry | to update the changes made in [RFC8447]. Do we expect this note to stay in the final RFC? I don’t see how this is useful for readers once the doc is published as an RFC. Consider adding a note to the RFC editor to remove this. # Section 1: List of changes CURRENT: This specification updates the "Recommended" column in TLS registries to define a third value "D" for items that are discouraged. Should we also mention the other change about the comment column? At least the abstract/intro should be in sync on the list of changes. # Section 3: Adding "Recommended" Column This update is not about adding a new column, but updating permitted values. I would update the title to reflect the update. You may consider, for example: OLD: Adding "Recommended" Column NEW: Updating Permitted Value in "Recommended" Column # Section 3: Check on “Y”/”N” Value and applicability of a mechanism RFC8447 used to have: “This table has been generated by marking Standards Track RFCs as "Y" and all others as "N".”. That guidance seems “mechanical” to me. This document seems to have a slightly modified guidance as it says: CURRENT: Y: Indicates that the IETF has consensus that the item is RECOMMENDED. This only means that the associated mechanism is fit for the purpose for which it was defined. Careful reading of the documentation for the mechanism is necessary to understand the applicability of that mechanism. The IETF could recommend mechanisms that have limited applicability, but will provide applicability statements that describe any limitations of the mechanism or necessary constraints on its use. Does this mean that all “Y” have been checked based on “Careful reading ..” and their applicability is called? I’m asking this question, especially that we also have the following under “N”: CURRENT: The IETF might have consensus to leave an items marked as "N" on the basis of its having limited applicability or usage constraints. # Section 3: Why Implementers only? What about those who will make use of a mechanism? ## Consider mention users as well CURRENT: Implementers SHOULD consult the … Any reason why users are not listed here? The wording in the Security Section is better IMO as it covers both: “Implementers and users need to check that…” ## I see the intent here for the use of normative language “SHOULD”, but we can’t actually enforce this. ## Explicit “it” + avoid confusion about the use of normative language Maybe: OLD: conditions under which it SHOULD NOT or MUST NOT be used. NEW: conditions under which an item “SHOULD NOT” or “MUST NOT” be used. # Section 3.1: picky CURRENT: For the registries discussed in the subsequent sections this note is updated with a sentence describing the "D" value as follows: Agree. The wording of the first sentence is also tweaked, but the meaning is same as in the registry, though. IANA registry has the following: If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. # IESG Approval is also covered by 8126! There many occurrences in the doc where 8126 is systematically provided as reference to Standard action only. Please consider updating all these occurrences as follows: OLD: Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action [RFC8126] or IESG Approval. NEW: Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action (Section 4.9 of [RFC8126]) or IESG Approval (Section 4.10 of [RFC8126]). # “IANA SHALL …” constructs Like other uses in an IANA consideration sections, the normative language is not justified to request an action. Please consider making these changes (many occurrences) OLD: IANA SHALL NEW: IANA is requested OLD: A reference to this document SHALL be added to these entries. NEW: IANA is requested to add a reference to this document for these entries. # Section 5: nits OLD: Cipher suites marked as anon do not provide any authentication and are vulnerable to man-in-the-middle attacks and are deprecated NEW: Ciphersuites marked as anon do not provide any authentication and are vulnerable to on-path attacks and are deprecated # Section 8: nit OLD: the the TLS Certificate Types NEW: the TLS Certificate Types # Section 9: use the IANA registry name OLD: TLS HashAlgorithm Registry registry NEW: TLS HashAlgorithm registry # Section 10: nit OLD: SignatureAlgorithm registry registry NEW: SignatureAlgorithm registry # Section 11: Use the IANA registry name (several occurrences to fix) OLD: TLS ClientCertificateType Identifier registry NEW: TLS ClientCertificateType Identifiers registry # Section 13: Lack of recommended note, intentional? Is it OK that there is no note on the recommended column in this IANA registry, while a recommended column is present? is the new note in 3.1 apply here as well? # Section 15: standard CURRENT: The intent of the Specification Required standard What does this mean? Do we meant registration policy? Please reword. Thanks. # Section 16: WG CURRENT: The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported groups. This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported groups. This was especially true of national cipher suites. Which WG? I guess you mean "TLS WG". This is confusing especially that the document reflect an IETF consensus, not a specific WG. Cheers, Med _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
