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

Commentary: Address comments from IESG evaluation . Due to the holiday season , we may not get prompt confirmation that these changes fully resolve the comments .
Paragraph (version A):
This document provides usage guidance for external Pre-Shared Keys
(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
This document lists TLS security properties provided by PSKs under
certain assumptions, and then demonstrates how violations of these
assumptions lead to attacks.  This document discusses PSK use cases
and provisioning processes.  This document provides advice for
applications to help meet these assumptions.  This document also
lists the privacy and security properties that are not provided by
TLS 1.3 when external PSKs are used.
Paragraph (version B):
This document provides usage guidance for external Pre-Shared Keys
(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
It lists TLS security properties provided by PSKs under certain
assumptions, and then demonstrates how violations of these
assumptions lead to attacks.  Advice for applications to help meet
these assumptions is provided.  It also discusses PSK use cases and
provisioning processes.  Finally, it lists the privacy and security
properties that are not provided by TLS 1.3 when external PSKs are
used.
Paragraph (version A):
If PSK is not combined with fresh ephemeral key exchange, then
compromise of any group member allows the attacker to passively
read (and actively modify) all traffic.
Paragraph (version B):
If PSK is not combined with fresh ephemeral key exchange, then
compromise of any group member allows the attacker to passively
read (and actively modify) all traffic, including past traffic.
Paragraph (version A):
Entropy properties of external PSKs may also affect TLS security
properties.  For example, if a high entropy PSK is used, then PSK-
only key establishment modes provide expected security properties for
TLS, including, for example, including establishing the same session
keys between peers, secrecy of session keys, peer authentication, and
downgrade protection.  See RFC8446, Section E.1 for an explanation of
these properties.  However, these modes lack forward security.
Forward security may be achieved by using a PSK-DH mode, or,
alternatively, by using PSKs with short lifetimes.
Paragraph (version B):
Entropy properties of external PSKs may also affect TLS security
properties.  For example, if a high entropy PSK is used, then PSK-
only key establishment modes provide expected security properties for
TLS, including establishing the same session keys between peers,
secrecy of session keys, peer authentication, and downgrade
protection.  See RFC8446, Section E.1 for an explanation of these
properties.  However, these modes lack forward security.  Forward
security may be achieved by using a PSK-DH mode, or, alternatively,
by using PSKs with short lifetimes.
Paragraph (version A):
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 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.  There was no
attempt to prioritize the examples in any particular order.
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; see security-con for considerations when using
early data with external PSKs.
Paragraph (version B):
Intra-data-center communication.  Machine-to-machine communication
within a single data center or point-of-presence (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):
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):
Some secrets may be baked into or hardware or software device
components.  Moreover, when this is done at manufacturing time,
secrets may be printed on labels or included in a Bill of
Materials for ease of scanning or import.
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 fewer
buttons.  When the TOFU approach is not suitable, entering the key
would require typing it on a constrained UI.
Paragraph (version B):
Some secrets may be baked into hardware or software device
components.  Moreover, when this is done at manufacturing time,
secrets may be printed on labels or included in a Bill of
Materials for ease of scanning or import.
Paragraph (version A):
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):
Each endpoint SHOULD know the identifier of the other endpoint with
which it 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.