Hi all, In general the content here is good, though there's a few things in sections 4 and 4.1 that I'm not entirely sure about, and we might stand to be a bit more clear about to what extent TLS pre 1.3 is in scope (we do talk about it in some places, but the declared scope is only (D)TLS 1.3 plus cTLS (which is a 1.3 variant).
I made a PR with some basically editorial suggestions: https://github.com/tlswg/external-psk-design-team/pull/68 It seems like we might want to have a sentence or two in the introduction or terminology section defining what we mean by "external PSK" (e.g., "a symmetric secret key provided to the TLS library as an external input"). I think the first mention of "provisioned out-of-band" is currently not until ยง6... Should we have a note that when we write "TLS 1.3" it applies to DTLS and cTLS as well? Section 1 The abstract notes that this document "lists the privacy and security properties that are not provided by TLS when external PSKs are used", but I don't see much analogous to that in the Introduction. (The overlap between Abstract and Introduction is a bit higher than I prefer, but I don't have any suggested improvements.) Section 4 External PSK authentication in TLS allows endpoints to authenticate connections using previously established keys. These keys do not provide protection of endpoint identities (see Section 5), nor do We might want to disambiguate between "authentication of endpoint identities" and "confidentiality protection for endpoint identities", since just "protection" could read as either one. (Also applies to the following sentence.) they provide non-repudiation (one endpoint in a connection can deny the conversation). Protection of endpoint identities and protection against an endpoint denying the conversation are possible when a fresh TLS handshake is performed. I don't understand the last sentence -- is this a "fresh TLS handshake" using the same external PSK that we just said doesn't provide these things? Are we equating "fresh handshake" with "uses certificates"? Section 4.1 2. If PSK with DH is used, then compromise of a group member that actively completes connections with other group members can read (and modify) traffic. I can't parse this sentence: "If <X>, then compromise of <Y>" needs another clause, like "allows the attacker to <Z>", but currently the sentence parses with <Y> basically consuming the rest of the sentence. (Also, does "actively complete" mean to receive, initiate, or both?) 4. If a group member is compromised, then the attacker can perform all of the above attacks. I'm not sure I understand how this item adds value, since (2) and (3) explicitly assume "compromise of a group member" and for the case of (1) compromising a group member naturally satisfies "any group member can...". Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described below. Note that this class of attack is not possible if each member uses the SNI extension [RFC6066] and terminates the connection on mismatch. See [Selfie] for details. SNI only authenticates the server identity; it seems that if (e.g.) A and B both initiate connections to C at the same time, the attacker can make C think that A and B's connections/identities are swapped. (I don't remember if [Selfie] directly touches on this attack or not.) This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also violates the downgrade protection property. [...] I think we might want to say a little more about how this violdates the downgrade protection property (or "fails to provide downgrade protection", since violating a property is a somewhat unusual phrasing). Most of the instances of the word "downgrade" in RFC 8446 rever to (TLS) version downgrade, with essentially only the definition of "downgrade protection" in Appendix E.1 mentioning arbitrary "cryptographic parameters" that should be the same on both peers as in the absence of an attack. But in this setup we have three entities involved, and it's not clear to which pair we should apply the test -- if A was intending to talk to C, it would get the same parameters it actually did. And the attacker doesn't really affect the negotiation per se -- it can't force a weaker cipher just because C has it enabled. A has to offer it, and it has to be the one that C actually picks. So the negotiated ciphersuite would only be different if B and C have different most-preferred ciphers from A's list, which is perhaps a bit harder to achieve in practice than just "C supports weaker ciphers". Section 6.1 * Some secrets may be baked into or hardware or software device components. Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import. It seems like we should comment on the risks that printing the baked-in PSK on a label or in a BoM incur for the security of the system of as whole. Section 7 2. Unless other accommodations are made, each PSK MUST be restricted We probably want a few more words about what the accommodations are for (e.g., "to mitigate the risks of group-shared PSK usage" or "to provide explicit node identification"). Section 8 This one-paragraph security considerations feels quite short for a document of this nature. Perhaps we want a note about "security considerations are discussed throughout this memo" (plus transition phrase) as well as the current content? I might also consider an introductory sentence to reiterate that the biggest concerns specific to PSK relate to the determination of the identities of the communicating parties and the increase in risk as the PSK is shared more broadly (which seems to be a summary of the remaining content of the section). Section 10.1 It seems that we only reference DTLS 1.3 for our scope of applicability, which doesn't necessarily make it a normative reference. (cTLS is referenced in the same way but is classified as informative already.) NITS Section 5 PSK privacy properties are orthogonal to security properties described in Section 4. Traditionally, TLS does little to keep PSK identity information private. For example, an adversary learns IIRC, "traditionally" is on the NIST word list and will get flagged by Lars' review script and the RFC Editor. If you change it now, that will avoid getting pestered later (but changing it is not a hard requirement). Section 6.1 * Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: typing the PSK into the devices, or via web server masks (using a Trust On I don't think I know what a "web server mask" is. Section 7 3. Nodes using TLS 1.3 SHOULD use external PSK importers [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a client-server pair. [...] My read of the introduction is that we only provide guidance for (D)TLS 1.3 and cTLS, which means that importers will always be available. Do we need to specify "using TLS 1.3" here? Section 7.1.2 stack's internal session resumption cache. This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. I don't think that the TLS stack will give an indication to the callback that there was a collision, so "precedence over how to handle" may not be quite accurate. Maybe something like "the application's external PSK usage will typically take precedence over the internal session resumption path"? Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
