Change:
Sorted the attacks into three classes.
NAME do you want to take a stab at this?
Fixed in .
... and describe attacks in all-honest (general) model.
NAME can you take this?
TLS 1.3 tries to maintain 8 security properties in the handshake. A naïve sharing of PSKs, even assuming only honest but curious participants know the key, can violate these properties. Let the group of peers who know the key be A, B, and C. Let the attacker compromise C. A sends a to B. The attacker intercepts it, and passes it to C. C, under the direction of the attacker, sends a to B, acting as A. B responds C thinking he is responding to A. C responds to A. A completes the handshake ostensibly with B, sending a message. C sends a message to B. B completes the handshake ostensibly with A. Although neither A nor B has been compromised, both have completed a session, ostensibly with each other, but have established different keys. Let the group of peers who know the key be A, B, and C. Let A complete a PSK handshake with B without performing a fresh DHE. C, an honest but curious agent, knows the PSK and can derive the session key. Let the group of peers who know the key be A, B, and C. A sends a to B. The attacker redirects the message to C. C responds to A. A completes the handshake ostensibly with B, sending a message. The attacker redirects the message to C. C completes the handshake ostensibly with A. Let the group of peers who know the key be A, B, and C. Let the attacker compromise C. A sends a with no key share to C. The attacker repeats the to B. B responds to C. The attacker repeats the response to A. A completes the handshake ostensibly with C, sending a message. The attacker repeats the message to B. B completes the handshake ostensibly with C. Although neither A nor B has been compromised they have each established a session with the attacker with the same key. Let the group of peers who know the key be A, B, and C. Let A and B support strong and weak cipher suites, but let C support only weaker cipher suites. A sends a to B. The attacker redirects the message to C. C responds to A choosing a weak cipher suite. A completes the handshake ostensibly with B, sending a message with a weak cipher suite. The attacker redirects the message to C. C completes the handshake ostensibly with A. Let the group of peers who know the key be A, B, and C. Let A establish a PSK session with B, without a fresh DHE. Let the attacker record the session. Let the attacker compromise C. The attacker can decrypt the recorded session, even though she compromised C after A and B completed their session. Let the group of peers who know the key be A, B, and C. Let the attacker compromise A. A sends a to B. The attacker intercepts the and responds using the PSK learned from A. A completes the handshake ostensibly with B, sending a message. Although B was never compromised the attacker is able to impersonate B to A. Although this has not seen any analysis, this appears to be secure, because even honest entities cannot distinguish each other.
Fixed in .
LGTM -- we can clean up nits after!

Discussion:
4.1. <del> TODO(jonathan): writeme Shared session keys: Session key secrecy: Peer authentication: Session key uniqueness: Downgrade protection: Forward secrecy: KCI protection: Endpoint identity protection: 5. The TLS external PSK authentication makes the implicit assumption that each PSK is known only to one client and one server, which do not switch roles with the same PSK. </del> As discussed in use-cases, there are use cases where multiple clients or multiple servers share a PSK.  In such cases, TLS only authenticates the entire group.  Not only can a compromised group member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them <del> in unintended ways.  This rerouting is a type of identity misbinding attack Sethi. </del> <ins> in unintended ways. The TLS external PSK authentication mechanism 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, standard TLS 1.3 security properties are invalidated. TLS 1.3 tries to maintain the following eight security properties: Matching the same session keys; Session key secrecy; Peer authentication; Session key uniqueness; Downgrade protection; Forward secrecy with respect to long-term keys; Key Compromise Impersonation (KCI) resistance; and Endpoint identity protection. A naive sharing of PSKs, even assuming only honest but curious participants know the key, can violate all these properties, bar one. Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode.  (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13- cert-with-extern-psk.) In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption does not hold. 4.1.1. This attack simply requires the adversary to reroute messages without changing any of their contents. Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: 1.  "A" sends a "ClientHello" to "B" 2. The attacker intercepts the message and redirects it to "C" 3.  "C" responds with to "A" 4.  "A" sends a "Finished" message to "B" "A" has completed the handshake, ostensibly with "B".  5.  The attacker redirects the "Finished" message to "C" "C" has completed the handshake, ostensibly with "A". 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.  This rerouting is a type of identity misbinding attack Sethi.  Selfie attack Selfie is a special case of the rerouting attack against a group member that can act both as TLS server and client.  In the Selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint. 4.1.2. If the client performs a PSK-based handshake without a DHE exchange, then another trivial attack is possible. Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows.  1.  "A" sends a "ClientHello" to "B", without including a key share 2.  The handshake completes as expected This attack violates the secrecy of session keys property, because even an honest but curious "C" can decrypt the session between "A" and "B".  This attack also violates forward secrecy, because a future compromise of "C" reveals the contents of the session, however RFC8446 notes that PSK-based handshakes without a fresh DHE do not achieve this property. 4.1.3. If the attacker compromises a client or server then the session is definitionally insecure, however sharing the key with more than one client and one server means that compromise of a different actor can lead to attacks. Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows.  1.  Let the attacker compromise "C" 2. "A" sends a "ClientHello" to "B" 3.  The attacker intercepts the message and creates a new "ClientHello" 4.  The attacker sends the new "ClientHello" to "B" 5.  "B" responds to "A" 6.  The attacker intercepts the message and creates a new response 7.  The attacker sends the new response to "A" 8.  "A" sends a "Finished" message to "B" "A" has completed the handshake, ostensibly with "B".  9.  The attacker intercepts the "Finished" message and creates a new "Finished" message 10.  The attacker sends the new "Finished" message to "B" "B" has completed the handshake, ostensibly with "A". This attack, and minor variants of it, violate the remaining properties outlined above.  The attack violates the same session keys property, as "A" and "B" have each completed a session, ostensibly with each other, and yet do not agree on the session key.  If "A" does not send a key share, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </ins> <del> Selfie attack Selfie is a special case of the rerouting attack against a group member that can act both as TLS server and client. In the selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint. </del> <ins> 5. </ins> 6.