Barry Leiba has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection
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-tls13-cert-with-extern-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From the shepherd writeup: There was concern raised that no one has reported implementation of this draft. The document has experimental status and that helped gain working group consensus to move it forward. ...and... The document has been reviewed and is supported by a few working group members. Not everyone in the group agrees that it is needed, This seems to imply that making it Experimental was a tactic to get it through the working group, and that concerns me a bit, though not enough to get to DISCUSS. I would be happier if there were some discussion in the document about how we would determine that it is, indeed, needed and useful, and when we might know that we should move it to Standards Track or else abandon it. Unfortunately, I suspect the answer to that is that we won’t know until we have quantum computers to mount attacks with, and that won’t be until certain places freeze over. I realize that preparing for maybe someday having quantum computers and what they might someday do is an exercise that not everyone will want to spend time working on and implementing. Some editorial comments, for which no reply is necessary: — Section 4 — Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension. What happens if it is? Should this say that if they appear together the server aborts the handshake with an "illegal_parameter" alert? The hash algorithm MUST be set when the PSK is established, with a default of SHA-256. If it MUST be set, how is there a default? — Section 5 — If the server responds with a HelloRetryRequest message, then the client sends another ClientHello message as described in Section 4.1.2 of [RFC8446], including the same "tls_cert_with_extern_psk" extension as the original ClientHello message or abort the handshake. “, or aborts” (the comma closes the comma before “including”, and “aborts” is parallel to “sends”). — Section 5.1 — Most of those extension are not impacted in any way. This section discusses the impacts on the other extensions. Make it “those extensions”. And I would rephrase the second sentence as, “This section discusses the impacts on the extensions that are affected.” The "psk_key_exchange_modes" extension restricts both the use of PSKs offered in this ClientHello and those which the server might supply via a subsequent NewSessionTicket. “Use of” needs to be factored out of the “both” clause: NEW ...restricts the use of both the PSKs offered in this ClientHello and those that the server might supply... END — Section 7 — the external PSKs and searching the resulting small set of possibilities, rather than brute force searching the whole key space. “and search”, and “brute-force” The reasoning is explained in [K2016] (see Section 4.2). I suggest “The reasoning is explained in Section 4.2 of [K2016].” Otherwise it sounds like you should see 4.2 of this doc (and I think the html links will be generated better this way). This specification does not require that external PSK is known only “that the external PSK” _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
