Draft: draft-ietf-tls-external-psk-guidance

Commentary: While trying to find a home for this text , I did some other unrelated cleanup . I could n't find a spot better than the security considerations . cc 
 Slightly different placement than I suggested , but it works too . 
 From This is a great point . We can add some language which describes considerations for external PSK reuse with early data . 
  : 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 , 
 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 .
Paragraph (version A):
PSK ciphersuites were first specified for TLS in 2005.  Now, PSKs are
an integral part of the TLS version 1.3 specification RFC8446.  TLS
resumption PSKs from external PSKs which have been provisioned out-
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.
Paragraph (version B):
PSK ciphersuites were first specified for TLS in 2005.  PSKs are now
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-
of-band.  This section describes known use cases and provisioning
processes for external PSKs with TLS.
Paragraph (version B):
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.
Paragraph (version A):
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
with early data.
Paragraph (version B):
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
with early data; see security-con for considerations when using
early data with external PSKs.
Paragraph (version A):
Use of PSK ciphersuites are optional when securing RADIUS RFC2865
with TLS as specified in RFC6614.
Paragraph (version A):
The Generic Authentication Architecture (GAA) defined by 3GGP
mentions that TLS-PSK can be used between a server and user
equipment for authentication GAA.
Paragraph (version A):
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.
Paragraph (version B):
Securing RADIUS RFC2865 with TLS.  PSK ciphersuites are optional
for this use case, as specified in RFC6614.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Examples of PSK provisioning processes are included below.
Paragraph (version B):
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.