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

Commentary: Resolve the comments from
Paragraph (version A):
Finally, in addition to these weaknesses, sharing a PSK across nodes
may negatively affects deployments.  For example, revocation of
individual group members is not possible without changing the
authentication key for all members.
Paragraph (version B):
Finally, in addition to these weaknesses, sharing a PSK across nodes
may negatively affect deployments.  For example, revocation of
individual group members is not possible without changing the
authentication key for all members.
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 oppress handshakes or application
data from a specific device by blocking, delaying, or rate-limiting
traffic.  Techniques for mitigating these risks require analysis and
are out of scope for this document.
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.  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 analysis and
are out of scope for this document.
Paragraph (version A):
The exact provisioning process depends on the system requirements and
threat model.  Generally, use of a single PSK shared between more
than one node is not recommended, even if other accommodations are
made, such as client certificate authentication after PSK-based
connection establishment.  See recommendations.
Paragraph (version B):
The exact provisioning process depends on the system requirements and
threat model.  Whenever possible, avoid sharing a PSK between nodes;
however, sharing a PSK among several node is sometimes unavoidable.
When PSK sharing happens, other accommodations SHOULD be used as
discussed in recommendations.
Paragraph (version A):
Where possible the main PSK (that which is fed into the importer)
SHOULD be deleted after the imported keys have been generated.
This protects an attacker from bootstrapping a compromise of one
node into the ability to attack connections between any node;
otherwise the attacker can recover the main key and then re-run
the importer itself.
Paragraph (version B):
Where possible the main PSK (that which is fed into the importer)
SHOULD be deleted after the imported keys have been generated.
This prevents an attacker from bootstrapping a compromise of one
node into the ability to attack connections between any node;
otherwise the attacker can recover the main key and then re-run
the importer itself.