TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-07

* 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).