[TLS] Barry Leiba's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

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”