Ballot for draft-ietf-tls-tls13-cert-with-extern-psk
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
* Section 7. The paragraphs that start with “In this extension, the external PSK preserves secrecy if the EC(DH) key agreement” …” and “In the future, if the (EC)DH key agreement ..” seem to be saying the same thing differently. * Section 7. It’s worth mentioning somewhere the obvious thing – how to generate, distribute, manage the external PSKs is out of scope for this specification. * Section 7. Per “TLS 1.3 [RFC8446] has received careful security analysis, and some informal reasoning shows that the addition of this extension does not introduce any security defects”, is there a citation for this “informal reasoning”? Otherwise, it’s a soft statement. * Editorial Nits: - Section 3. Typo. s/inclue/include/ - Section 5.1. Typo. s/extension are/extensions are/ - Section 5.1. /Most of those extension are not impacted in any way. This section discusses the impacts on the other extensions./Most of those extension are not impacted in any way by this specification. However, this section discusses the extensions that require additional consideration./ - Section 5.1. Typo. s/may be know to other partiers/may be known to other parties/ - Section 5.1. Typo. s/know to other parties/known to other parties/ - Section 7. Typo. s/that external PSK/that the external PSK/
Side note: I'm perfectly fine with the track, or Informational -- it seems interesting and useful (as much as I could understand, at any rate :-))
Thanks for the work on this document and its described mechanism. ID Nits reports: == Unused Reference: 'RFC2104' is defined on line 504, but no explicit reference was found in the text
Building on a point Barry made, I think it would be useful to distinguish in the document whether this spec is experimental because we are waiting for quantum computers to materialize, or whether it is experimental because current implementors want to gain more experience with it before standardization. That way if it does come back at some future point on the standards track the context for why it was experimental in the first place will be there. Please respond to the Gen-ART reviewer.
I agree with Alissa's comment about the status.
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”
Just a small thing to double-check: I wonder if this sentence would actually require an update to RFC8446: "TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server." Or maybe it should be phrased differently, just: "If the "tls_cert_with_extern_psk" extension is negotiated, certificate-based authentication is allowed for both the client and the server." I guess it depends on what exactly is said in RFC8446 (and I didn't went and tried to find it). And as a side note, it is usually recommended to provide the link to the registry in the IANA section (to make life for IANA easier).