Original text:
OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide the PSK identity (as a character string) and key (as a byte string).  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del>  mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for <del> any operations.  TLS version 1.3 RFc8446 follows the same practice of </del>  specifying the psk identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1>). Implementations such as OpenSSL and mbedTLS nonetheless treat psk_identities as character strings and use string operators such <del> as strcmp on the psk identity. </del>  Implementations also assign default identities to PSKs (for example, the string 'Client_identity') if none are configured. 4. <del> Against a passive attacker AdvP or active attacker AdvA, desired privacy properties might include: Peer Authentication.  The client's view of the peer identity should reflect the server's identity.  If the client is authenticated, the server's view of the peer identity should match the client's identity.  Moreover, the client's view of the peer identity should not match its own identity Selfie. Channel Binding.  External PSKs should include channel bindings from any protocol run a priori to provision the PSKs. Identity Confidentiality.  AdvP should learn no information about the external PSK or its identifier.  Similarly, AdvA should be unable to replay ClientHello messages and learn information about the PSK. Identity Unlinkability.  AdvP should be unable to link two or more connections together that use the same external PSK. Unlinkability for the PSK receiver, i.e., ensuring that the recipient of a ClientHello with a given PSK k cannot link k to a prior session, is out of scope.  (PSKs are explicitly designed to support mutual authentication.) 4.1. 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 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: </del>  Matching the same session keys; Downgrade protection; <del> Forward secrecy with respect to long-term keys; </del>  <del> Key Compromise Impersonation (KCI) resistance; and </del>  <del> Endpoint identity protection. </del>  <del> 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.) </del>  In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption changing any of their contents. Let the group of peers who know the key be "A", "B", and "C".  The <del> 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". </del>  This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also then another trivial attack is possible. Let the group of peers who know the key be "A", "B", and "C".  The <del> attack proceeds as follows.  1.  "A" sends a "ClientHello" to "B", without including a key share 2.  The handshake completes as expected </del>  This attack violates the secrecy of session keys property, because even an honest but curious "C" can decrypt the session between "A" lead to attacks. Let the group of peers who know the key be "A", "B", and "C".  The <del> 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". </del>  This attack, and minor variants of it, violate the remaining properties outlined above.  The attack violates the same session keys 5.  6. <del> TODO </del>  7. <del> TODO </del> 

Reviewer comments:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .

Revised text:
OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake.  <ins> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for  <ins> any operations.  TLS version 1.3 RFC8446 follows the same practice of </ins> specifying the psk identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1>). Implementations such as OpenSSL and mbedTLS nonetheless treat psk_identities as character strings and use string operators such  <ins> as "strcmp" on the psk identity. </ins> Implementations also assign default identities to PSKs (for example, the string 'Client_identity') if none are configured. 4.  <ins> TLS 1.3 tries to maintain the following seven security properties: </ins> Matching the same session keys; Downgrade protection;  <ins> Forward secrecy with respect to long-term keys; and </ins>  <ins> Key Compromise Impersonation (KCI) resistance. </ins>  <ins> To achieve these properties, the 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.  Section violations discusses attacks that are possible when this occurs. </ins>  <ins> 4.1. 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 in unintended ways.  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.) </ins> In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption changing any of their contents. Let the group of peers who know the key be "A", "B", and "C".  The  <ins> attack proceeds as follows: "A" sends a "ClientHello" to "B". The attacker intercepts the message and redirects it to "C". "C" responds with to "A". "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B". The attacker redirects the "Finished" message to "C".  "C" has completed the handshake, ostensibly with "A". </ins> This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also then another trivial attack is possible. Let the group of peers who know the key be "A", "B", and "C".  The  <ins> attack proceeds as follows: "A" sends a "ClientHello" to "B", without including a key share. The handshake completes as expected. </ins> This attack violates the secrecy of session keys property, because even an honest but curious "C" can decrypt the session between "A" lead to attacks. Let the group of peers who know the key be "A", "B", and "C".  The  <ins> attack proceeds as follows: Let the attacker compromise "C". "A" sends a "ClientHello" to "B". The attacker intercepts the message and creates a new "ClientHello". The attacker sends the new "ClientHello" to "B". "B" responds to "A". The attacker intercepts the message and creates a new response. The attacker sends the new response to "A". "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B". The attacker intercepts the "Finished" message and creates a new "Finished" message. The attacker sends the new "Finished" message to "B".  "B" has completed the handshake, ostensibly with "A". </ins> This attack, and minor variants of it, violate the remaining properties outlined above.  The attack violates the same session keys 5. <ins> Given the desired security goals from TODO, applications which make use of external PSKs MUST adhere to the following requirements: Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a server MUST use distinct PSKs when acting as the client from when it is acting as the server. Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk- importer when configuring PSKs for individual TLS connections. Each PSK MUST be at least 128-bits long. </ins> 6.  <ins> PSK privacy properties are orthogonal to security properties described in sec-properties.  Traditionally, TLS does little to keep PSK identity information private.  For example, an adversary learns information about the external PSK or its identifier by virtue of it appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when using external PSKs if these risks. In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can link successive connections that use the same external PSK together. Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication. </ins> 7.  <ins> This document makes no IANA requests. </ins>