Original text:
one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened. <del> use-cases discusses use cases where it is desirable for multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS only authenticates the entire group, 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. 4. <del> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. 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.  This prevents redirection attacks. Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk- importer when configuring PSKs for each pair of TLS client and server.  If a distinct importer is used for each pair, then this satisfies condition (2). Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated.  This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself. 5. </del> 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 Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication. <del> 6. </del>  Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005.  Now, PSK is an integral part of the TLS version 1.3 authentication with the usage of a certificate after successfully establishing the connection with a PSK. <del> 6.1. </del>  Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: typing the secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import. <del> 6.2. </del>  PSK provisioning systems are often constrained in application- specific ways.  For example, although one goal of provisioning is to identities.  Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS-PSK. <del> 6.3. </del>  Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL. <del> 6.3.1. </del>  Section 5.1 of RFC4279 mandates that the PSK identity should be first converted to a character string and then encoded to octets using UTF- 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 specifying the psk identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1>). </del>  <del> Other assumptions unique to different stacks are listed below. </del>  <del> gnuTLS treats psk identities as usernames. </del>  7.  This document makes no IANA requests.

Reviewer comments:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!

Revised text:
one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened.  <ins> As discussed in use-cases, there are use cases where it is desirable for multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS only authenticates the entire group, 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. 4.  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 Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication.  <ins> 5. </ins> Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005.  Now, PSK is an integral part of the TLS version 1.3 authentication with the usage of a certificate after successfully establishing the connection with a PSK.  <ins> 5.1. </ins> Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: typing the secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.  <ins> 5.2. </ins> PSK provisioning systems are often constrained in application- specific ways.  For example, although one goal of provisioning is to identities.  Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS-PSK.  <ins> 6. Applications MUST use external PSKs that adhere to the following requirements: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. 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 a pair of TLS client and server. Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated.  This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself. 6.1. </ins> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.  <ins> 6.1.1. </ins> Section 5.1 of RFC4279 mandates that the PSK identity should be first converted to a character string and then encoded to octets using UTF- 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 operation.  TLS version 1.3 RFC8446 follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1> in the specification).  RFC8446 also requires that the PSK identities are at least 1 byte and at the most 65535 bytes in length.  Although RFC8446 does not place strict requirements on the format of PSK identities, we do however note that the format of PSK identities can vary depending on the deployment: </ins>  <ins> The PSK identity MAY be a user configured string when used in protocols like Extensible Authentication Protocol (EAP) RFC3748. gnuTLS for example treats PSK identities as usernames. </ins>  <ins> PSK identities MAY have a domain name suffix for roaming and federation. Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. identity-collision discusses some implication of collisions between external and resumption PSKs. 6.1.1.1. </ins> 7. <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 multiple nodes.  I-D.ietf-tls-external-psk-importer helps in mitigating rerouting and selfie style reflection attacks when the PSK is shared among multiple nodes.  This is achieved by correctly using the node identifiers in the ImportedIdentity.context construct specified in I-D.ietf-tls-external-psk-importer.  It is RECOMMENDED that each endpoint selects one globally unique identifier and uses it in all PSK handshakes.  The unique identifier can, for example, be one of its MAC addresses, a 32-byte random number, or its Universally Unique IDentifier (UUID) RFC4122.  Each endpoint SHOULD know the identifier of the other endpoint with which its wants to connect and SHOULD compare it with the other endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other. 8. </ins> This document makes no IANA requests.