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

Commentary: Addresses , , and . 
 ... and do n’t prohibit or otherwise interfere with PAKEs . ( Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band . ) 
 Fixed in . 
 Fixed in . 
 with the general recommendation and invariant : Identities should be unique across all nodes , roles , and keys . each use case , how a part of the invariant is violated and leads to one of the known attacks . 
 Fixed in .
Paragraph (version A):
OpenSSL and BoringSSL: Applications specify support for external
PSKs via distinct ciphersuites.  They also then configure
callbacks that are invoked for PSK selection during the handshake.
These callbacks must provide the PSK identity (as a character
string) and key (as a byte string).  They are typically invoked
with a PSK hint, i.e., the hint provided by the server as per
RFC4279.  The PSK length is validated to be between [1, 256] bytes
upon selection.
Paragraph (version B):
OpenSSL and BoringSSL: Applications specify support for external
PSKs via distinct ciphersuites.  They also then configure
callbacks that are invoked for PSK selection during the handshake.
These callbacks must provide a PSK identity (as a character
string) and key (as a byte string).  (If no identity is provided,
a default one is assumed.)  They are typically invoked with a PSK
hint, i.e., the hint provided by the server as per RFC4279.  The
PSK length is validated to be between [1, 256] bytes upon
selection.
Paragraph (version A):
Implementations such as OpenSSL and mbedTLS nonetheless treat
psk_identities as character strings and use string operators such
as strcmp on the psk identity.
Paragraph (version B):
Implementations such as OpenSSL and mbedTLS nonetheless treat
psk_identities as character strings and use string operators such
as "strcmp" on the psk identity.
Paragraph (version A):
Peer Authentication.  The client's view of the peer identity
should reflect the server's identity.  If the client is
authenticated, the server's view of the peer identity should match
the client's identity.  Moreover, the client's view of the peer
identity should not match its own identity Selfie.
Paragraph (version A):
Channel Binding.  External PSKs should include channel bindings
from any protocol run a priori to provision the PSKs.
Paragraph (version A):
Identity Confidentiality.  AdvP should learn no information about
the external PSK or its identifier.  Similarly, AdvA should be
unable to replay ClientHello messages and learn information about
the PSK.
Paragraph (version A):
Identity Unlinkability.  AdvP should be unable to link two or more
connections together that use the same external PSK.
Paragraph (version A):
As discussed in use-cases, there are use cases where multiple clients
or multiple servers share a PSK.  In such cases, TLS only
authenticates the entire group.  Not only can a compromised group
member impersonate another group member, but a malicious non-member
can reroute handshakes between honest group members to connect them
in unintended ways.
Paragraph (version A):
The TLS external PSK authentication mechanism implicitly assumes one
fundamental property: each PSK is known to exactly one client and one
server, and that these never switch roles.  If this assumption is
violated, standard TLS 1.3 security properties are invalidated.
Paragraph (version A):
Endpoint identity protection.
Paragraph (version B):
Key Compromise Impersonation (KCI) resistance.
Paragraph (version B):
To achieve these properties, the external PSK authentication
mechanism implicitly assumes one fundamental property: each PSK is
known to exactly one client and one server, and that these never
switch roles.  If this assumption is violated, standard TLS 1.3
security properties are invalidated.  Section violations discusses
attacks that are possible when this occurs.
Paragraph (version A):
Let the group of peers who know the key be "A", "B", and "C".  The
attack proceeds as follows: 1.  "A" sends a "ClientHello" to "B" 2.
The attacker intercepts the message and redirects it to "C" 3.  "C"
responds with to "A" 4.  "A" sends a "Finished" message to "B" "A"
has completed the handshake, ostensibly with "B".  5.  The attacker
redirects the "Finished" message to "C" "C" has completed the
handshake, ostensibly with "A".
Paragraph (version B):
The attacker intercepts the message and redirects it to "C".
Paragraph (version B):
"C" responds with to "A".
Paragraph (version B):
The attacker redirects the "Finished" message to "C".  "C" has
completed the handshake, ostensibly with "A".
Paragraph (version B):
"A" sends a "ClientHello" to "B", without including a key share.
Paragraph (version B):
The handshake completes as expected.
Paragraph (version A):
Let the group of peers who know the key be "A", "B", and "C".  The
attack proceeds as follows.  1.  Let the attacker compromise "C" 2.
"A" sends a "ClientHello" to "B" 3.  The attacker intercepts the
message and creates a new "ClientHello" 4.  The attacker sends the
new "ClientHello" to "B" 5.  "B" responds to "A" 6.  The attacker
intercepts the message and creates a new response 7.  The attacker
sends the new response to "A" 8.  "A" sends a "Finished" message to
"B" "A" has completed the handshake, ostensibly with "B".  9.  The
attacker intercepts the "Finished" message and creates a new
"Finished" message 10.  The attacker sends the new "Finished" message
to "B" "B" has completed the handshake, ostensibly with "A".
Paragraph (version B):
Let the attacker compromise "C".
Paragraph (version B):
The attacker intercepts the message and creates a new
"ClientHello".
Paragraph (version B):
The attacker sends the new "ClientHello" to "B".
Paragraph (version B):
"B" responds to "A".
Paragraph (version B):
The attacker intercepts the message and creates a new response.
Paragraph (version B):
The attacker sends the new response to "A".
Paragraph (version B):
The attacker intercepts the "Finished" message and creates a new
"Finished" message.
Paragraph (version B):
The attacker sends the new "Finished" message to "B".  "B" has
completed the handshake, ostensibly with "A".
Paragraph (version B):
Each PSK MUST NOT be shared between with more than two logical
nodes.  As a result, an agent that acts as both a client and a
server MUST use distinct PSKs when acting as the client from when
it is acting as the server.
Paragraph (version B):
Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk-
importer when configuring PSKs for individual TLS connections.
Paragraph (version B):
Each PSK MUST be at least 128-bits long.
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 B):
In addition to linkability in the network, external PSKs are
intrinsically linkable by PSK receivers.  Specifically, servers can
link successive connections that use the same external PSK together.
Preventing this type of linkability is out of scope, as PSKs are
explicitly designed to support mutual authentication.