Original text:
Abstract This document provides usage guidance for external Pre-Shared Keys <del> (PSKs) in Transport Layer Security (TLS) version 1.3 as defined in RFC 8446.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  It discusses PSK use 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.  It also lists the privacy and security properties that are not provided by TLS when external PSKs are used. </del>  1. This document provides guidance on the use of external Pre-Shared <del> Keys (PSKs) in Transport Layer Security (TLS) version 1.3 RFC8446. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </del>  There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys (PSKs) in TLS.  This document aims to reduce that gap. <del> The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Compact TLS I-D.ietf-tls-ctls. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 4. <del> 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).  Protection of endpoint identities and protection against an endpoint denying the conversation are possible when a fresh TLS handshake is performed. </del>  PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and Any group member can impersonate any other group member. <del> 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. </del>  <del> If PSK without DH is used, then compromise of any group member allows the attacker to passively read (and modify) all traffic. If a group member is compromised, then the attacker can perform all of the above attacks. </del>  Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described <del> below.  Note that this class of attack is not possible if each member uses the SNI extension RFC6066 and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity.  See Selfie for details. </del>  To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: The attacker redirects the "Finished" message to "C".  "C" has completed the handshake with "A". <del> 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 </del>  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 incorporating EPSKs described in I-D.ietf-tls-external-psk- importer. <del> Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role.  (The two logical nodes MAY be the same, in different roles.)  Two acceptable accommodations are described in I-D.ietf-tls-external- psk-importer: (1) exchanging client and server identifiers over the TLS connection after the handshake, and (2) incorporating identifiers for both the client and the server into the context string for an EPSK importer. </del>  Nodes using TLS 1.3 SHOULD use external PSK importers I-D.ietf- tls-external-psk-importer when configuring PSKs for a client- 8.  It is NOT RECOMMENDED to share the same PSK between more than one client and server.  However, as discussed in use-cases, there are application scenarios that may rely on sharing the same PSK among

Reviewer comments:
This deals with many comments from the AD Evaluation. The comment on section 6.1 still needs to be resolved, and the NITS need to be addressed.
Chris's suggestions generally seem reasonable

Revised text:
Abstract This document provides usage guidance for external Pre-Shared Keys  <ins> (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1. This document provides guidance on the use of external Pre-Shared  <ins> Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this document uses the term TLS to refer to all such versions.  External PSKs are symmetric secret keys provided to the TLS protocol implementation as external inputs.  External PSKs are provisioned out-of-band.  This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys (PSKs) in TLS.  This document aims to reduce that gap.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 4.  <ins> 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). Protection of endpoint identities and protection against an endpoint denying the conversation are possible only when a fresh TLS handshake that authenticates the endpoints with certificates is performed. </ins> PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and Any group member can impersonate any other group member.  <ins> If PSK is combined with DH, then compromise of a group member that knows the resulting DH shared secret will enable the attacker to read (and modify) traffic. </ins>  <ins> If PSK is not combined with DH, 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  <ins> below.  Note that a partial mitigiation against this class of attack is available: each group member includes the SNI extension RFC6066 and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity.  See Selfie for details. </ins> To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: The attacker redirects the "Finished" message to "C".  "C" has completed the handshake with "A".  <ins> In this attack, peer authentication is not provided.  Also, if "C" supports a weaker set of cipher suites than "B", cryptographic algorithm downgrade attacks might be possible.  This rerouting is a type of identity misbinding attack Sethi.  Selfie attack Selfie is a </ins> 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 incorporating EPSKs described in I-D.ietf-tls-external-psk- importer.  <ins> Unless other accommodations are made to mitigate the risks of PSKs know to a group, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role.  (The two logical nodes MAY be the same, in different roles.)  Two acceptable accommodations are described in I-D.ietf-tls-external-psk-importer: (1) exchanging client and server identifiers over the TLS connection after the handshake, and (2) incorporating identifiers for both the client and the server into the context string for an EPSK importer. </ins> Nodes using TLS 1.3 SHOULD use external PSK importers I-D.ietf- tls-external-psk-importer when configuring PSKs for a client- 8. <ins> Security considerations are provided throughout this document.  It bears repeating that there are concerns related to the use of external PSKs regarding proper identification of TLS 1.3 endpoints and additional risks when external PSKs are known to a group. </ins> It is NOT RECOMMENDED to share the same PSK between more than one client and server.  However, as discussed in use-cases, there are application scenarios that may rely on sharing the same PSK among