Original text:
4. <del> When using external PSK authentication, the use of previously established PSKs allows TLS endpoints to authenticate the endpoint identities.  However, these keys do not provide privacy protection of endpoint identities (see endpoint-privacy), nor do they provide non- repudiation (one endpoint in a connection can deny the conversation). </del>  PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and 4.1. <del> 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 done naively by having all members share a common key, then TLS authenticates only group membership, and the security of the overall system is inherently rather brittle.  There are a number of obvious weaknesses here: </del>  Any group member can impersonate any other group member. <del> If PSK is combined with DH, then compromise of a group member that knows the resulting DH shared secret will enable the attacker to passively read (and actively modify) traffic. </del>  <del> If PSK is not combined with DH, then compromise of any group member allows the attacker to passively read (and actively modify) all traffic. </del>  Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described 4.2. Entropy properties of external PSKs may also affect TLS security <del> properties.  In particular, if a high entropy PSK is used, then PSK- only key establishment modes are secure against both active and passive attack.  However, they lack forward security.  Forward security may be achieved by using a PSK-DH mode. </del>  In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks computers. There are also use cases where PSKs are shared between more than two <del> entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova): </del>  Group chats.  In this use-case, group participants may be provisioned an external PSK out-of-band for establishing follows: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST <del> be at least 128 bits long, and SHOULD be combined with a DH exchange, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3, for forward secrecy.  As discussed in sec- properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided. If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed.  Note that no such mechanisms have yet been standardised, and further that these mechanisms will not </del>  necessarily follow the same architecture as the process for incorporating external PSKs described in I-D.ietf-tls-external- psk-importer.

Reviewer comments:
NIT: Might be better to say: Just drops some redundant words.
I think some things that should be more positive: -- For both PSK authentication and PSK key exchange without (EC)DHE the bad security properties such as lack of identity protection and lack of forward secrecy can be overcome by using one-time PSKs. External PSKs with short lifetimes are quite common in many real deployments. I think this should be mentioned. -- I think quantum resistance should be mentioned earlier in the document. Quantum resistance is a security property, not use a use case. Some things that should be more negative: -- In the list in 4.1 you can add "4. Any group member can blame any other group member." Other comments: -- "then PSK-only key establishment modes are secure against both active and passive attack." I think this you need to describe the exact attacks you have in mind rather than use the work "secure". My view would be that acceptable security in 2021 includes both identity protection and forward secrecy. But more on a system level, then necessarily by TLS itself. -- "DH" I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher suites in obsolete versions of TLS. -- "As discussed in Section 6, there are use cases where it is desirable for multiple clients or multiple servers to share a PSK." "However, as discussed in Section 6, there are application scenarios that may rely on sharing the same PSK among multiple nodes." Unless you have any real deployments to share, I think this should be reformulated. These are Gedankenexperiments used to illustrate the attack, not real-world applications. I would reformulate and remove "desirable", group PSKs should be very much discouraged. Suggestion: "As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] describes scenarios where multiple clients or multiple servers share a PSK."

Revised text:
4.  <ins> The use of a previously established PSK allows TLS nodes to authenticate the endpoint identities.  It also offers other benefits, including resistance to attacks in presence of quantum computes; see entropy for related discussion.  However, these keys do not provide privacy protection of endpoint identities, nor do they provide non- repudiation (one endpoint in a connection can deny the conversation); see endpoint-privacy for related discussion. </ins> PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and 4.1.  <ins> As discussed in use-cases, to demonstrate their attack, AASS19 describes scenarios where multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS authenticates only group membership, and the security of the overall system is inherently rather brittle.  There are a number of obvious weaknesses here: </ins> Any group member can impersonate any other group member.  <ins> If PSK is combined with a fresh ephemeral key exchange, then compromise of a group member that knows the resulting shared secret will enable the attacker to passively read (and actively modify) traffic. </ins>  <ins> If PSK is not combined with fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively read (and actively modify) all traffic. </ins> Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described 4.2. Entropy properties of external PSKs may also affect TLS security  <ins> properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for TLS, including, for example, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </ins> In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks computers. There are also use cases where PSKs are shared between more than two  <ins> entities.  Some examples below (as noted by Akhmetzyanova et al. AASS19): </ins> Group chats.  In this use-case, group participants may be provisioned an external PSK out-of-band for establishing follows: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST  <ins> be at least 128 bits long, and SHOULD be combined with an ephemeral key exchange exchange, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3, for forward secrecy.  As discussed in sec-properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided.  If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed.  Note that no such mechanisms have yet been standardised, and further that these mechanisms will not </ins> necessarily follow the same architecture as the process for incorporating external PSKs described in I-D.ietf-tls-external- psk-importer.