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

Commentary: cc 
 I think that all of the concern have been addressed . can you confirm ?
Paragraph (version A):
When using external PSK authentication, the use of previously
established PSKs allows TLS endpoints to authenticate the endpoint
identities.  However, these keys do not provide privacy protection of
endpoint identities (see endpoint-privacy), nor do they provide non-
repudiation (one endpoint in a connection can deny the conversation).
Protection of endpoint identities and protection against an endpoint
denying the conversation are possible only when a fresh TLS handshake
that authenticates the endpoints with certificates is performed.
Paragraph (version B):
When using external PSK authentication, the use of previously
established PSKs allows TLS endpoints to authenticate the endpoint
identities.  However, these keys do not provide privacy protection of
endpoint identities (see endpoint-privacy), nor do they provide non-
repudiation (one endpoint in a connection can deny the conversation).
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.  Depending on the PSK identity, a passive
attacker may also be able to identify the device, person, or
enterprise running the TLS client or TLS server.  An active attacker
can also use the PSK identity to suppress handshakes or application
data from a specific device by blocking, delaying, or rate-limiting
traffic.  Techniques for mitigating these risks require further
analysis and are out of scope for this document.
Paragraph (version B):
PSK privacy properties are orthogonal to security properties
described in sec-properties.  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.  Depending on the PSK identity, a passive attacker may
also be able to identify the device, person, or enterprise running
the TLS client or TLS server.  An active attacker can also use the
PSK identity to suppress handshakes or application data from a
specific device by blocking, delaying, or rate-limiting traffic.
Techniques for mitigating these risks require further analysis and
are out of scope for this document.
Paragraph (version A):
Many industrial protocols assume that PSKs are distributed and
assigned manually via one of the following approaches: typing the
PSK into the devices, or via web server masks (using a Trust On
First Use (TOFU) approach with a device completely unprotected
before the first login did take place).  Many devices have very
limited UI.  For example, they may only have a numeric keypad or
even less number of buttons.  When the TOFU approach is not
suitable, entering the key would require typing it on a
constrained UI.
Paragraph (version B):
Many industrial protocols assume that PSKs are distributed and
assigned manually via one of the following approaches: typing the
PSK into the devices, or using a Trust On First Use (TOFU)
approach with a device completely unprotected before the first
login did take place.  Many devices have very limited UI.  For
example, they may only have a numeric keypad or even less number
of buttons.  When the TOFU approach is not suitable, entering the
key would require typing it on a constrained UI.
Paragraph (version A):
Nodes using TLS 1.3 SHOULD use external PSK importers I-D.ietf-
tls-external-psk-importer when configuring PSKs for a client-
server pair.  Importers make provisioning external PSKs easier and
less error prone by deriving a unique, imported PSK from the
external PSK for each key derivation function a node supports.
See the Security Considerations in I-D.ietf-tls-external-psk-
importer for more information.
Paragraph (version B):
Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk-
importer when configuring PSKs for a client-server pair when
applicable.  Importers make provisioning external PSKs easier and
less error prone by deriving a unique, imported PSK from the
external PSK for each key derivation function a node supports.
See the Security Considerations in I-D.ietf-tls-external-psk-
importer for more information.
Paragraph (version A):
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 behavior
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.
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 behavior
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's external PSK usage will
typically take precedence over the internal session resumption path.
Paragraph (version A):
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.
Paragraph (version B):
specified in I-D.ietf-tls-external-psk-importer.  One solution would
be for each endpoint to select 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.
Paragraph (version B):
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.