Guidance for External Pre-Shared Key (PSK) Usage in TLS
draft-ietf-tls-external-psk-guidance-06

[S4; nit]

* s/quantum computes/quantum computers/?

[S4.2; nit]

* "including, for example, including ..." -> "including, for example, ..."

[S5.2; nit]

* "or even less number of buttons" -> "or even fewer buttons", perhaps

* "baked into or hardware or software" -> "baked into hardware or software"

[S5.3; question]

* What does "routable" mean in an identities context?  Perhaps there is
  some simpler rewording that preserves the essential meaning (or maybe
  this is well-understood and I'm just not up to speed yet).

  I could not find "rout"-stemmed words in draft-mattsson-emu-eap-tls-psk.

[S8; nit]

* s/beynond/beyond/

Thank you for the work on this document.

Many thanks to Martin Thomson for his careful review: https://mailarchive.ietf.org/arch/msg/art/6b5V1TEJL_PB2dc3Xfm62KFGqW8/ , and thanks to the authors for addressing his comments.

I only had time to scan the document, but did not find any major ART issues.

Francesca

Thanks to Martin Thomson for his ARTART review.

A stylistic point: The Abstract is made up of five sentences all of which start "This document".  It's a bit of a rigid read.  Maybe something like this?

   This document provides usage guidance for external Pre-Shared Keys
   (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
   It lists TLS security properties provided by PSKs under
   certain assumptions, and then demonstrates how violations of these
   assumptions lead to attacks.  It also discusses PSK use cases
   and provisioning processes.  Advice for
   applications to help meet these assumptions is provided.  Finally,
   it lists the privacy and security properties that are not provided by
   TLS 1.3 when external PSKs are used.

Section 4.1 contains this, which I can't quite parse:

   To illustrate the rerouting attack, consider the group of peers who
   know the PSK be A, B, and C.

Should there be a "to" after "PSK"?

In Section 8:

   Each endpoint SHOULD know the identifier of the other endpoint with
   which its wants to connect and SHOULD compare it with the other

s/its/it/

Thanks for working on this document. I read this document and didn't noticed any transport related issues.

[Sorry for duplicate email, I pressed the wrong button...]

Thank you for the work put into this document. The document offers good guidances and is easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Sean Turner for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 4.1 --
A wild guess (as I do not know the details of TLS 1.3), but if a group member is compromised and no ephemeral keys were used, then isn't the attacker able to read even the past/recorded traffic ? 

-- Section 5.1 --
Suggest to expand "PoP".

Also wonder about the German eID use case... While the BSI specification allows for using PSK, it does not appear as the recommended mode by BSI. I.e., does this reference help the case for this I-D ? Suggest to remove it.

I also wonder why quantum resistance is not at the top ;-)

-- Section 5.2 --
About the IoT "UI", I would assume that some USB ports could also be used. Or are USB/bluetooth/... considered as UI ?

-- Section 5.3 --
"each pair of nodes has a unique key pair" is puzzling as PSK usually consist of a unique key and not a key pair. What am I missing ?
 

== NITS ==
Section 5.2 "among several node is" (plural ?)
Section 8 "extend beynond proper identification"

Thanks for this document.  I find it always useful, and enlightening, when this sort of guidance is published.

One minor nit/question on 7.  Privacy Considerations

   TLS does little to keep PSK identity
   information private.  For example, an adversary learns information
   about the external PSK or its identifier by virtue of it appearing in
   cleartext in a ClientHello.

I wasn't sure what "it" in the last sentence refers to.  I would potentially read that as being the external PSK, and hence the external PSK appears in cleartext in a ClientHello.  I don't know TLS, but this seemed surprising.  Hence you may want to consider whether this sentence should be tweaked to make it clearer.

Thanks,
Rob