Guidance for External Pre-Shared Key (PSK) Usage in TLS
draft-ietf-tls-external-psk-guidance-06
Yes
(Benjamin Kaduk)
No Objection
John Scudder
(Alvaro Retana)
(Martin Duke)
Note: This ballot was opened for revision 04 and is now closed.
Roman Danyliw
Yes
Comment
(2021-12-15 for -04)
Sent
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/
Erik Kline
No Objection
Comment
(2021-12-11 for -04)
Sent
[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)
Not sent
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
Murray Kucherawy
No Objection
Comment
(2021-12-14 for -04)
Sent
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/
Zaheduzzaman Sarker
No Objection
Comment
(2021-12-14 for -04)
Not sent
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)
Sent
[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 IESG member
Yes
Yes
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(for -04)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2021-12-15 for -04)
Sent
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