Barry Leiba has entered the following ballot position for draft-ietf-uta-tls-bcp-09: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- One very simple point: -- Section 2 -- A number of security-related terms in this document are used in the sense defined in [RFC4949]. Terminology definitions need to be in normative references; 4949 should be normative. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't want to make these a DISCUSS, but I would appreciate a discussion: -- Section 3.1.1 -- On the SHOULD NOTs here: Is there any reason one might violate them *other than* that the other side doesn't support TLS 1.2 ? If not, is it worth saying that explicitly? Is it even worth changing "SHOULD NOT negotiate TLS version [x]" to "MUST NOT negotiate TLS version [x] unless no higher version is available in the negotiation" ? How can I evaluate each of the following "SHOULD"s? Why might I have a good reason not to comply with each of them?: -- Section 3.2 -- o When applicable, Web servers SHOULD use HSTS to indicate that they are willing to accept TLS-only clients. -- Section 3.3 -- Implementations and deployments SHOULD disable TLS-level compression ([RFC5246], Section 6.2.2). -- Section 3.5 -- TLS clients SHOULD apply the same validation policy for all certificates received over a connection, bind the master secret to the full handshake, and bind the abbreviated session resumption handshake to the original full handshake. -- Section 4.2.1 -- Servers SHOULD prefer this cipher suite over weaker cipher suites whenever it is proposed, even if it is not the first proposal. For the above set of "SHOULD" questions, I'm looking for something in the document that can help readers understand why these are not "MUST", and when and why they might make an informed decision not to abide by them. --- One other non-blocking comment; no discussion needed: -- Section 3.1.2 -- Nit: "correlates to Version 1.2 of TLS 1.2" -- take out one of the "1.2" ? _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
