Skip to main content

Guidance for External PSK Usage in TLS
draft-ietf-tls-external-psk-guidance-06

Yes

(Benjamin Kaduk)

No Objection

Alvaro Retana
John Scudder
Martin Duke

Note: This ballot was opened for revision 04 and is now closed.

Roman Danyliw Yes

Comment (2021-12-15 for -04)
Thank you to Rich Salz for the SECDIR review.

** Section 6.1.  Consider providing information references for OpenSSL, BoringSSL, mbedTLS, gnuTLS and wolfSSL

** Section 6.1.  Should it be noted that some libraries (E.g., OpenSSL, BoringSSL, mbedTLS) support PSK lengths below the threshold recommend in this document (i.e., smaller than 128-bits per Section 6)?

** Editorial nits:

-- Section 4.1.  Typo. s/mitigiation/mitigation/
-- Section 6.  Duplicate word. s/exchange exchange/exchange/
-- Section 8. Typo. s/beynond/beyond/

Alvaro Retana No Objection

Erik Kline No Objection

Comment (2021-12-11 for -04)
[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/

Francesca Palombini No Objection

Comment (2021-12-16 for -04)
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

John Scudder No Objection

Martin Duke No Objection

Murray Kucherawy No Objection

Comment (2021-12-14 for -04)
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/

Robert Wilton No Objection

Comment (2021-12-15 for -04)
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

Zaheduzzaman Sarker No Objection

Comment (2021-12-14 for -04)
Thanks for working on this document. I read this document and didn't noticed any transport related issues.

Éric Vyncke No Objection

Comment (2021-12-10 for -04)
[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"

(Benjamin Kaduk; former steering group member) Yes

Yes (for -04)