Tommy Jensen has entered the following ballot position for draft-ietf-tls-mldsa-04: Discuss
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-mldsa/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to thank the editors, LC reviewers, expert reviews, and the shepherd for their insights. This document is straightforward and easy to understand. However, I do have concerns the other ADs have not expressed. I am choosing to ballot DISCUSS to enable a discussion, as I believe that document clarifications can resolve my concerns. TL;DR: every other document defining Recommended=N at publication for this registry explains why =N or carries explicit lack of IETF endorsement, but this one does neither. This needs to be explained one way or the other in the document. Now for the longer version: There have been five RFCs (listed below) published that define new entries with Recommended=N values since RFC 8447 introduced the column to the registry. Four of the five were published on the Independent Submission stream as Informational, and the fifth was published as a TLS WG document as a Proposed Standard. The first four all have some form of “the IETF does not endorse this” (exact quotes below), and the fifth contains normative requirements that specifically ensure implementations do not use it by default. The fifth also specifically defines entries from an already existing standard used in TLS 1.2 that makes the track choice understandable. This document, on the other hand, is a product of the TLS WG, is Informational, and has no disclaimers about lack of endorsement or requirements to avoid default use. From this information alone, I would expect it to use Recommended=Y. Since it doesn’t, this is the first document to request publication as an RFC with SignatureScheme registry entries with Recommended=N without an explanation as to why they aren’t recommended. That concerns me, because there are one of two possibilities that lead to different requests from me: the WG has concerns that are not documented (and I request they be documented), or the WG does not have concerns because this document’s definitions are somehow significantly more trustworthy than the other Recommended=N documents (in which case this should be explained in the document, and also explain why it cannot be Recommended=Y). Otherwise, implementers or software vendor evaluators could easily read these different RFCs and conclude this one must be less =N than the others. I look forward to the discussion. These are the five RFCs I am referring to: RFC 8734 defines three new entries with Recommended=N, was published on the ISE, and states that “This approach is not endorsed by the IETF”. RFC 8998 defines one new entry with Recommended=N, was published on the ISE, and states that “The use of these algorithms with TLS 1.3 is not endorsed by the IETF.” RFC 9189 defines two new entries with Recommended=N, was published on the ISE, and states that “This approach does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types.” RFC 9367 defines seven new entries with Recommended=N, was published on the ISE, and states that “The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document.” RFC 9963 defines three new entries with Recommended=N (see Table 1), but it was NOT published on the ISE. The document uses normative requirements to avoid usage by default, and it justifies its existence by explaining why it unblocks adoption of TLS 1.3 and avoid unnecessary downgrades to TLS 1.2 when in some deployments the only alternative is to break communication entirely. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- On the question of track: I agree with the sentiment of my fellow ADs that Experimental seems to be more appropriate for this draft, but I think depending on how my DISCUSS points are addressed, Informational could end up being appropriate based on precedent set by other documents editing this registry. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
