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

Commentary: NIT : Might be better to say : Just drops some redundant words . 
 I think some things that should be more positive : -- For both PSK authentication and PSK key exchange without ( EC)DHE the bad security properties such as lack of identity protection and lack of forward secrecy can be overcome by using one - time PSKs . External PSKs with short lifetimes are quite common in many real deployments . I think this should be mentioned . -- I think quantum resistance should be mentioned earlier in the document . Quantum resistance is a security property , not use a use case . Some things that should be more negative : -- In the list in 4.1 you can add " 4 . Any group member can blame any other group member . " Other comments : -- " then PSK - only key establishment modes are secure against both active and passive attack . " I think this you need to describe the exact attacks you have in mind rather than use the work " secure " . My view would be that acceptable security in 2021 includes both identity protection and forward secrecy . But more on a system level , then necessarily by TLS itself . -- " DH " I think it would be good to change all “ DH ” to “ DHE ” and all “ Diffie - Hellman ” to “ ephemeral    ” to avoid confusion with the static DH cipher suites in obsolete versions of TLS . -- " As discussed in Section 6 , there are use cases where it is desirable for multiple clients or multiple servers to share a PSK . " " However , as discussed in Section 6 , there are application scenarios that may rely on sharing the same PSK among multiple nodes . " Unless you have any real deployments to share , I think this should be reformulated . These are Gedankenexperiments used to illustrate the attack , not real - world applications . I would reformulate and remove " desirable " , group PSKs should be very much discouraged . Suggestion : " As discussed in Section 6 , to illustrate their attack , [  ] describes scenarios where multiple clients or multiple servers share a PSK . "
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).
Paragraph (version B):
The use of a previously established PSK allows TLS nodes to
authenticate the endpoint identities.  It also offers other benefits,
including resistance to attacks in presence of quantum computes; see
entropy for related discussion.  However, these keys do not provide
privacy protection of endpoint identities, nor do they provide non-
repudiation (one endpoint in a connection can deny the conversation);
see endpoint-privacy for related discussion.
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
passively read (and actively modify) traffic.
Paragraph (version A):
If PSK is not combined with DH, then compromise of any group
member allows the attacker to passively read (and actively modify)
all traffic.
Paragraph (version B):
If PSK is combined with a fresh ephemeral key exchange, then
compromise of a group member that knows the resulting shared
secret will enable the attacker to passively read (and actively
modify) 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.
Paragraph (version A):
Entropy properties of external PSKs may also affect TLS security
properties.  In particular, if a high entropy PSK is used, then PSK-
only key establishment modes are secure against both active and
passive attack.  However, they lack forward security.  Forward
security may be achieved by using a PSK-DH mode.
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, 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 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, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange
Mode in TLS 1.3, 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.
If only low-entropy keys are available, then key establishment
mechanisms such as Password Authenticated Key Exchange (PAKE) that
mitigate the risk of offline dictionary attacks SHOULD be
employed.  Note that no such mechanisms have yet been
standardised, and further that these mechanisms will not
necessarily follow the same architecture as the process for
incorporating external PSKs described in I-D.ietf-tls-external-
psk-importer.
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 an
ephemeral key exchange exchange, e.g., by using the "psk_dhe_ke"
Pre-Shared Key Exchange Mode in TLS 1.3, 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.  If only low-entropy keys are available, then
key establishment mechanisms such as Password Authenticated Key
Exchange (PAKE) that mitigate the risk of offline dictionary
attacks SHOULD be employed.  Note that no such mechanisms have yet
been standardised, and further that these mechanisms will not
necessarily follow the same architecture as the process for
incorporating external PSKs described in I-D.ietf-tls-external-
psk-importer.