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

Commentary: Builds on , and , and . cc -- please review so we can submit today ! 
 There are two numbered lists both of which only seem to have 1s ? I see that you have removed the text on security weaknesses of PSKs ( lack of identity protection / forward secrecy etc . ) and also removed the reference to RFC 8773 . I am completely fine with both as long as we provide a convincing answer to  's review . 
 Markdown handles the numbering for us . We have a section on identity protection , and the recommendations discuss forward secrecy , so I think more is redudant . No , that 's still there . 
  wrote : There also several weaknesses / limitation that are hinted at in RFC 8446 which apply for two - party PSK authenticated connections . As this is a guidance document for all uses of external PSK , I think this document should bring up and expand upon : Key Compromise Impersonation ( KCI ) resistance Protection of endpoint identities Forward secret with respect to long - term keys ( psk_ke only ) An additional security property given by signature authentication but not psk authentication is non - repudiation . As stated by Wikipedia “ By this property , an entity that has signed some information can not at a later time deny having signed it . ” 
 This is a fair comment and I do n't see any reason not to add these 
 can you please send a PR ? 
 Closing as resolved ( by ) . 
 The draft says “ OpenSSL and BoringSSL : Applications specify support for external PSKs via distinct ciphersuites . ”  wrote : I assume this is not the case for TLS 1.3 as the cipher suites in TLS 1.3 are independent of the authentication . 
 I guess it would help to clarify . In my opinion , we should only look at APIs of TLS 1.3 . 
 I fixed this directly on main . 
 The draft currently says " It is NOT RECOMMENDED to share the same PSK between more than one client and server . "  says : group PSK violates both “ peer authentication ” and “ downgrade protection property ” . It also violates “ secrecy of the session keys ” . Two - party PSK already does not provide “ Key Compromise Impersonation ( KCI ) resistance ” and “ Protection of endpoint identities ” and pskkey does not provide “ Forward secret with respect to long - term keys ” . So when pskke is used in a group , the only property left is “ Uniqueness of the session keys” ... I am skeptical to introduce this new group PSK mode in an informal guidance document . If group PSK should be allowed , it should be more clearly declared as a new mode of TLS 1.3 and the security properties given and not given should be more clearly stated . 
 I guess  thinks NOT RECOMMENDED is not sufficient and we should stronger language like SHALL NOT .
Paragraph (version A):
This document provides usage guidance for external Pre-Shared Keys
(PSKs) in TLS.  It lists TLS security properties provided by PSKs
under certain assumptions and demonstrates how violations of these
assumptions lead to attacks.  This document also discusses PSK use
cases, provisioning processes, and TLS stack implementation support
in the context of these assumptions.  It provides advice for
applications in various use cases to help meet these assumptions.
Paragraph (version B):
This document provides usage guidance for external Pre-Shared Keys
(PSKs) in TLS.  It lists TLS security properties provided by PSKs
under certain assumptions and demonstrates how violations of these
assumptions lead to attacks.  This document also discusses PSK use
cases, provisioning processes, and TLS stack implementation support
in the context of these assumptions.  It provides advice for
applications in various use cases to help meet these assumptions.
Privacy and security properties not provided by PSKs are also
included.
Paragraph (version A):
The external PSK authentication mechanism in TLS 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, then the security properties of TLS are severely weakened.
Paragraph (version B):
External PSK authentication in TLS allows endpoints to authenticate
connections using previously established keys.  These keys do not
provide protection of endpoint identities (see endpoint-privacy), nor
do they provide non-repudiation (one endpoint in a connection can
deny the conversation).  PSK authentication security 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, then the security properties of TLS are
severely weakened.
Paragraph (version A):
If a group member is compromised, then the attacker can
impersonate any group member (this follows from property (1)).
Paragraph (version A):
If PSK without DH is used, then compromise of any group member
allows the attacker to passively read all traffic.
Paragraph (version B):
If PSK with DH is used, then compromise of a group member that
actively completes connections with other group members can read
(and modify) traffic.
Paragraph (version B):
If PSK without DH is used, then compromise of any group member
allows the attacker to passively read (and modify) all traffic.
Paragraph (version B):
If a group member is compromised, then the attacker can perform
all of the above attacks.
Paragraph (version B):
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 A):
cpace and I-D.krawczyk-cfrg-opaque).
Paragraph (version B):
cpace and I-D.irtf-cfrg-opaque).
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.  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 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):
Quantum resistance: Some deployments may use PSKs (or combine them
with certificate-based authentication as described in RFC8773)
because of the protection they provide against quantum computers.