Original text:
6. <del> PSK ciphersuites were first specified for TLS in 2005.  Now, PSKs are </del>  an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out- <del> of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </del>  Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known Intra-data-center communication.  Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections <del> with early data. </del>  Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs, to Machine Technical Specification LwM2M states that LwM2M servers MUST support the PSK mode of DTLS. <del> Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614. </del>  <del> The Generic Authentication Architecture (GAA) defined by 3GGP mentions that TLS-PSK can be used between a server and user equipment for authentication GAA. </del>  Smart Cards.  The electronic German ID (eID) card supports authentication of a card holder to online services with TLS-PSK SmartCard. <del> Quantum resistance: Some deployments may use PSKs (or combine them with certificate-based authentication as described in RFC8773) because of the protection they provide against quantum computers. </del>  There are also use cases where PSKs are shared between more than two entities.  Some examples below (as noted by Akhmetzyanova et a central server (n keys for n devices), or have pairwise keys for communicating with each other (n^2 keys for n devices).  The exact provisioning process depends on the system requirements and threat model.  Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several node is sometimes unavoidable. When PSK sharing happens, other accommodations SHOULD be used as discussed in recommendations. <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 however important to remember that endpoints sharing the same group PSK can always impersonate each other.  9. This document makes no IANA requests.

Reviewer comments:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.

Revised text:
6.  <ins> PSK ciphersuites were first specified for TLS in 2005.  PSKs are now </ins> an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-  <ins> of-band.  This section describes known use cases and provisioning processes for external PSKs with TLS. 6.1. This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and one client, have been used for authentication in TLS. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known Intra-data-center communication.  Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections  <ins> with early data; see security-con for considerations when using early data with external PSKs. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs, to Machine Technical Specification LwM2M states that LwM2M servers MUST support the PSK mode of DTLS.  <ins> Securing RADIUS RFC2865 with TLS.  PSK ciphersuites are optional for this use case, as specified in RFC6614. </ins>  <ins> 3GPP server to user equipment authentication.  The Generic Authentication Architecture (GAA) defined by 3GGP mentions that TLS-PSK ciphersuites can be used between server and user equipment for authentication GAA. </ins> Smart Cards.  The electronic German ID (eID) card supports authentication of a card holder to online services with TLS-PSK SmartCard.  <ins> Quantum resistance.  Some deployments may use PSKs (or combine them with certificate-based authentication as described in RFC8773) because of the protection they provide against quantum computers. </ins> There are also use cases where PSKs are shared between more than two entities.  Some examples below (as noted by Akhmetzyanova et a central server (n keys for n devices), or have pairwise keys for communicating with each other (n^2 keys for n devices). <ins> 6.2. </ins> The exact provisioning process depends on the system requirements and threat model.  Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several node is sometimes unavoidable. When PSK sharing happens, other accommodations SHOULD be used as discussed in recommendations.  <ins> Examples of PSK provisioning processes are included below. </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> 6.3. </ins> PSK provisioning systems are often constrained in application- specific ways.  For example, although one goal of provisioning is to however important to remember that endpoints sharing the same group PSK can always impersonate each other. <ins> Considerations for external PSK usage extend beynond proper identification.  When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that contributes to key diversity between sessions.  As a result, when an external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. </ins> 9. This document makes no IANA requests.