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

Commentary: , . 
 please have a look . 
 This looks fine to me . 
 From this . 
 From this . 
 From : Section 7 , items 1 and 2 Justification : Both use the acronym " EPSK " without defining it . Existing text : " EPSK " Suggested text : " external PSK " in both places , consistent with other uses throughout the document . 7 , item 2 : Justification : Editorial correction . Existing text : " PSKs know to a group " . Suggested text : " PSKs known to a group " . 4.1 Justification : Items 2 and 3 respectively describe an attacker who can " read ( and modify ) " and " passively read ( and actively modify ) " traffic . Unless " read " is meant to be different than " passively read , " and " modify " differs from " actively modify , " . Suggested text : Either dropping " actively " and " passively " from item 3 , or moving the terms to item 2 so they qualify " modify " and " read " on first use and thus extend to both uses . 8 , paragraph 2 Justification : Editorial correction . Existing text : " and uses it " Suggested text : " and use it " ( matching change from " selects " to " to select " )
Mailing list commentary: Hello IESG , I hope this finds you well . Please find comments for “ draft - ietf - tls - external - psk - guidance-03 ” , below . The document is well written and the latest revision has improved the clarity of presentation – no concerns with publication , only minor editorial comments . Your feedback is greatly appreciated . Best , , Verisign
Paragraph (version A):
If PSK is combined with DH, then compromise of a group member that
knows the resulting DH shared secret will enable the attacker to
read (and modify) traffic.
Paragraph (version B):
If PSK is combined with DH, then compromise of a group member that
knows the resulting DH shared secret will enable the attacker to
passively read (and actively modify) traffic.
Paragraph (version A):
In contrast, if a low entropy PSK is used, then PSK-only key
establishment modes are subject to passive exhaustive search attacks
which will reveal the traffic keys.  PSK-DH modes are subject to
active attacks in which the attacker impersonates one side.  The
exhaustive search phase of these attacks can be mounted offline if
the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that
connection because those also depend on the Diffie-Hellman (DH)
exchange.  Low entropy keys are only secure against active attack if
a PAKE is used with TLS.  The Crypto Forum Research Group (CFRG) is
currently working on specifying recommended PAKEs (see I-D.irtf-cfrg-
cpace and I-D.irtf-cfrg-opaque, for the symmetric and asymmetric
cases, respectively).
Paragraph (version B):
In contrast, if a low entropy PSK is used, then PSK-only key
establishment modes are subject to passive exhaustive search attacks
which will reveal the traffic keys.  PSK-DH modes are subject to
active attacks in which the attacker impersonates one side.  The
exhaustive search phase of these attacks can be mounted offline if
the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that
connection because those also depend on the Diffie-Hellman (DH)
exchange.  Low entropy keys are only secure against active attack if
a password-authenticated key exchange (PAKE) is used with TLS.  The
Crypto Forum Research Group (CFRG) is currently working on specifying
recommended PAKEs (see I-D.irtf-cfrg-cpace and I-D.irtf-cfrg-opaque,
for the symmetric and asymmetric cases, respectively).
Paragraph (version A):
incorporating EPSKs described in I-D.ietf-tls-external-psk-
importer.
Paragraph (version B):
incorporating external PSKs described in I-D.ietf-tls-external-
psk-importer.
Paragraph (version A):
Unless other accommodations are made to mitigate the risks of PSKs
known to a group, each PSK MUST be restricted in its use to at
most two logical nodes: one logical node in a TLS client role and
one logical node in a TLS server role.  (The two logical nodes MAY
be the same, in different roles.)  Two acceptable accommodations
are described in I-D.ietf-tls-external-psk-importer: (1)
exchanging client and server identifiers over the TLS connection
after the handshake, and (2) incorporating identifiers for both
the client and the server into the context string for an EPSK
importer.
Paragraph (version B):
Unless other accommodations are made to mitigate the risks of PSKs
known to a group, each PSK MUST be restricted in its use to at
most two logical nodes: one logical node in a TLS client role and
one logical node in a TLS server role.  (The two logical nodes MAY
be the same, in different roles.)  Two acceptable accommodations
are described in I-D.ietf-tls-external-psk-importer: (1)
exchanging client and server identifiers over the TLS connection
after the handshake, and (2) incorporating identifiers for both
the client and the server into the context string for an external
PSK importer.
Paragraph (version A):
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.  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):
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.  One solution would
be for each endpoint to select one globally unique identifier and use
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.  Note that such persistent, global
identifiers have privacy implications; see endpoint-privacy.