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

Commentary: Changes to comments from   on 03 - Mar-2020 
 Section 3.1.1 : The text says : C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2 : The text says : A sends a ClientHello to B , without including a key share . It would be helpful to say " without including a key share extension . " Section 3.1.3 : I think a bit more explanation is needed here . Nonces can make the keys different , why does n't the nonce from the uncompromised party help in this example ? Section 4 : I would like to see a bit more context here . I agree with the recommendations for the intended environment , but they are overkill in the environment suggested by draft - ietf - tls - tls13 - cert - with - extern - psk . In fact , they are overkill if ( EC)DH is combined with the PSK at all . So , maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply . 
 Fixed by . 
 LGTM -- thanks ,  !
Paragraph (version A):
In the following sub-sections, we list attacks that demonstrate
violations of these properties when the fundamental PSK assumption
does not hold.  This list is not exhaustive, but merely highlights a
number of potential pitfalls.
Paragraph (version B):
In the following sub-sections, we list attacks that demonstrate
violations of these properties when the fundamental PSK assumption
does not hold.
Paragraph (version A):
"C" responds with to "A".
Paragraph (version B):
"C" responds with a "ServerHello" to "A".
Paragraph (version A):
"A" sends a "ClientHello" to "B", without including a key share.
Paragraph (version B):
"A" sends a "ClientHello" to "B", without including a key share
extension.
Paragraph (version A):
This attack, and minor variants of it, violate the remaining
properties outlined above.  The attack violates the same session keys
property, as "A" and "B" have each completed a session, ostensibly
with each other, and yet do not agree on the session key.  If "A"
does not send a key share, then the attacker can have a session with
"A" and a separate session with "B", where both sessions have the
same key.  This violates the uniqueness of session keys property.  In
the case of KCI resistance, where we assume the attacker has
compromised "A", the attacker can successfully impersonate "B" to "A"
using this pattern.
Paragraph (version B):
This attack, and minor variants of it, violate the remaining
properties outlined above.  The attack violates the same session keys
property, as "A" and "B" have each completed a session, ostensibly
with each other, and yet do not agree on the session key.  If "A"
does not send a key share extension, then the attacker can have a
session with "A" and a separate session with "B", where both sessions
have the same key.  Since the attacker has knowledge of all of the
messages and their content, the nonce in the handshake does not
prevent the attacker from computing the full key schedule.  This
violates the uniqueness of session keys property.  In the case of KCI
resistance, where we assume the attacker has compromised "A", the
attacker can successfully impersonate "B" to "A" using this pattern.
Paragraph (version A):
Each PSK SHOULD be seeded from a source with at least 128-bits of
entropy.
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.  Applications should take precautions when
using external PSKs if these risks are a concern.
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.  Applications should take precautions when
using external PSKs if these risks.
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
perhaps an interface with even fewer buttons.  When the TOFU
approach is not suitable, entering the key may require typing it
on a very constrained UI.  Moreover, PSK production lacks guidance
unlike user passwords.
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 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.  Moreover, PSK production lacks guidance unlike
user passwords.