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

Commentary: FIxed up : some nits on recommendations . I think the wording was a bit off on low entropy PSKs , so I lifted from ekrs text from earlier in the draft . some of the stack interface stuff on hints is not valid for TLS1.3 ( hints are TLS1.2 and earlier ) , so removed it . Some prelim text on collisions . For completeness , will take a look at gnutls and wolfssl order too . Note , even with the OpenSSL callback sequence , the application still does not know if there is a collision ... 
 Starter text from 
 can you please take this ? 
 Ping
Paragraph (version A):
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.
Paragraph (version B):
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 to mitigate these risks.
Paragraph (version A):
Some devices are provisioned PSKs via an out-of-band, cloud-based
syncing protocol.
Paragraph (version B):
Some devices provision PSKs via an out-of-band, cloud-based
syncing protocol.
Paragraph (version A):
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.
Paragraph (version B):
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.  As discussed in sec-properties, low
entropy PSKs, i.e., those derived from less than 128 bits of
entropy, are subject to attack and SHOULD be avoided.  Low entropy
keys are only secure against active attack if a Password
Authenticated Key Exchange (PAKE) is used with TLS.
Paragraph (version A):
Most major TLS implementations support external PSKs.  And all have a
common interface that applications may use when supplying them for
individual connections.  Details about existing stacks at the time of
writing are below.
Paragraph (version A):
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.
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.
Paragraph (version A):
mbedTLS: Client applications configure PSKs before creating a
connection by providing the PSK identity and value inline.
Servers must implement callbacks similar to that of OpenSSL.  PSK
lengths are validate to be between [1, 16] bytes.
Paragraph (version A):
gnuTLS: Applications configure PSK values, either as raw byte
strings or hexadecimal strings.  The PSK size is not validated.
Paragraph (version B):
Most major TLS implementations support external PSKs.  Stacks
supporting external PSKs provide interfaces that applications may use
when supplying them for individual connections.  Details about
existing stacks at the time of writing are below.
Paragraph (version B):
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.
These callbacks must provide a PSK identity and key.  The exact
format of the callback depends on the negotiated TLS protocol
version with new callback functions added specifically to OpenSSL
for TLS 1.3 RFC8446 PSK support.  The PSK length is validated to
be between [1, 256] bytes.  The PSK identity may be up to 128
bytes long.
Paragraph (version B):
mbedTLS: Client applications configure PSKs before creating a
connection by providing the PSK identity and value inline.
Servers must implement callbacks similar to that of OpenSSL.  Both
PSK identity and key lengths may be between [1, 16] bytes long.
Paragraph (version B):
gnuTLS: Applications configure PSK values, either as raw byte
strings or hexadecimal strings.  The PSK identity and key size are
not validated.
Paragraph (version B):
It is possible, though unlikely, that an external PSK identity may
clash with a resumption PSK identity.  The TLS stack implementation
and sequencing of PSK callbacks influences the application's
behaviour when identity collisions occur.  When a server receives a
PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the
application's registered callback function before checking the
stack's internal session resumption cache.  This means that if a PSK
identity collision occurs, the application will be given precedence
over how to handle the PSK.