Change:
Builds on , and , and . cc NAME NAME NAME -- please review so we can submit today!
There are two numbered lists both of which only seem to have 1s? I see that you have removed the text on security weaknesses of PSKs (lack of identity protection/forward secrecy etc.) and also removed the reference to RFC 8773. I am completely fine with both as long as we provide a convincing answer to John's review.
Markdown handles the numbering for us. We have a section on identity protection, and the recommendations discuss forward secrecy, so I think more is redudant. No, that's still there.
John wrote: There also several weaknesses/limitation that are hinted at in RFC 8446 which apply for two-party PSK authenticated connections. As this is a guidance document for all uses of external PSK, I think this document should bring up and expand upon: Key Compromise Impersonation (KCI) resistance Protection of endpoint identities Forward secret with respect to long-term keys (psk_ke only) An additional security property given by signature authentication but not psk authentication is non-repudiation. As stated by Wikipedia “By this property, an entity that has signed some information cannot at a later time deny having signed it.”
This is a fair comment and I don't see any reason not to add these
NAME can you please send a PR?
Closing as resolved (by ).
The draft says “OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.” John wrote: I assume this is not the case for TLS 1.3 as the cipher suites in TLS 1.3 are independent of the authentication.
I guess it would help to clarify. In my opinion, we should only look at APIs of TLS 1.3.
I fixed this directly on main.
The draft currently says "It is NOT RECOMMENDED to share the same PSK between more than one client and server." John says: group PSK violates both “peer authentication” and “downgrade protection property”. It also violates “secrecy of the session keys”. Two-party PSK already does not provide “Key Compromise Impersonation (KCI) resistance” and “Protection of endpoint identities” and pskkey does not provide “Forward secret with respect to long-term keys”. So when pskke is used in a group, the only property left is “Uniqueness of the session keys”...I am skeptical to introduce this new group PSK mode in an informal guidance document. If group PSK should be allowed, it should be more clearly declared as a new mode of TLS 1.3 and the security properties given and not given should be more clearly stated.
I guess John thinks NOT RECOMMENDED is not sufficient and we should stronger language like SHALL NOT.

Discussion:
cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. <ins> Privacy and security properties not provided by PSKs are also included. </ins> 1.

4. <del> The external PSK authentication mechanism in TLS implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened. </del> <ins> External PSK authentication in TLS allows endpoints to authenticate connections using previously established keys.  These keys do not provide protection of endpoint identities (see endpoint-privacy), nor do they provide non-repudiation (one endpoint in a connection can deny the conversation).  PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened. </ins> As discussed in use-cases, there are use cases where it is desirable for multiple clients or multiple servers to share a PSK.  If this is

Any group member can impersonate any other group member. <del> If a group member is compromised, then the attacker can impersonate any group member (this follows from property (1)). </del> <ins> 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. </ins> If PSK without DH is used, then compromise of any group member <del> allows the attacker to passively read all traffic. </del> <ins> allows the attacker to passively read (and modify) all traffic. </ins> <del> In addition to these, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as detailed 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.) </del> <ins> If a group member is compromised, then the attacker can perform all of the above attacks. </ins> <del> Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: </del> <ins> 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.)  Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".

non-member reroutes a connection from the client to the server on the same endpoint. <ins> Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively affects deployments.  For example, revocation of individual group members is not possible without changing the authentication key for all members. </ins> Entropy properties of external PSKs may also affect TLS security properties.  In particular, if a high entropy PSK is used, then PSK- only key establishment modes are secure against both active and

exchange.  Low entropy keys are only secure against active attack if a PAKE is used with TLS.  The Crypto Forum Research Group (CFRG) is currently working on specifying a standard PAKE (see I-D.irtf-cfrg- <del> cpace and I-D.krawczyk-cfrg-opaque). </del> <ins> cpace and I-D.irtf-cfrg-opaque). </ins> 5.

information about the external PSK or its identifier by virtue of it appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same <del> external PSK on the wire.  Techniques for mitigating these risks require analysis and are out of scope for this document. </del> <ins> external PSK on the wire.  Depending on the PSK identity, a passive attacker may also be able to identify the device, person, or enterprise running the TLS client or TLS server.  An active attacker can also use the PSK identity to oppress handshakes or application data from a specific device by blocking, delaying, or rate-limiting traffic.  Techniques for mitigating these risks require analysis and are out of scope for this document. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

authentication of a card holder to online services with TLS-PSK SmartCard. <ins> Quantum resistance: Some deployments may use PSKs (or combine them with certificate-based authentication as described in RFC8773) because of the protection they provide against quantum computers. </ins> There are also use cases where PSKs are shared between more than two entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova):