Change:
Resolve comments from Ben Smyth.
NAME can you please cut a new version of the draft?
Done. Revision -02 has been submitted.
I am getting a permission error when I try to set the tag for "draft-ietf-tls-external-psk-guidance-02". Everything else is done, and I have used my local file to submit the Internet-Draft. Please set the tag when you have a minute.

Discussion:
Abstract This document provides usage guidance for external Pre-Shared Keys <del> (PSKs) in TLS.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document also 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. Privacy and security properties not provided by PSKs are also included. </del> <ins> (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. </ins> 1. <ins> This document provides guidance on the use of external Pre-Shared 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. </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 <del> (PSKs) in TLS.  This document aims to reduce that gap.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also 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. </del> <ins> (PSKs) in TLS.  This document aims to reduce that gap. </ins> The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3.

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 <del> 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. </del> <ins> deny the conversation).  Protection of endpoint identities and protection against an endpoint denying the conversation are possible when a fresh TLS handshake is performed. 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 as discussed below. </ins> 4.1. 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 <del> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall </del> <ins> done naively by having all members share a common key, then TLS authenticates only group membership, and the security of the overall </ins> system is inherently rather brittle.  There are a number of obvious weaknesses here:

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.  See Selfie for details.)  Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: </del> <ins> 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. To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".

Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively affect deployments.  For example, revocation of <del> individual group members is not possible without changing the authentication key for all members. </del> <ins> individual group members is not possible without changing establishing a new PSK for all of the non-revoked members. </ins> 4.2.