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

Commentary: explain how tls exporter helps with KDF and mitigating selfie attacks . text on psk identity usage . 
 I left it empty for  ( 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 .  can add it when he gets around to his PR . 
 LGTM pending one orphan section !
Paragraph (version A):
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.
Paragraph (version A):
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).
Paragraph (version B):
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.
Paragraph (version B):
Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk-
importer when configuring PSKs for a pair of TLS client and
server.
Paragraph (version A):
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>).
Paragraph (version A):
Other assumptions unique to different stacks are listed below.
Paragraph (version A):
gnuTLS treats psk identities as usernames.
Paragraph (version B):
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.
Paragraph (version B):
PSK identities MAY have a domain name suffix for roaming and
federation.
Paragraph (version B):
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.
Paragraph (version B):
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.