Change:
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".

Discussion:
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.