Change:
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 <del> external PSK on the wire.  Techniques for mitigating these risks require analysis and are out of scope for this document. </del> <ins> 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. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

Discussion:
Builds on , and , and . cc NAME NAME NAME -- 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 John'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.
John 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 cannot at a later time deny having signed it.”
This is a fair comment and I don't see any reason not to add these
NAME 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.” John 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." John 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 John thinks NOT RECOMMENDED is not sufficient and we should stronger language like SHALL NOT.