Change:
cc NAME NAME
In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations that can be made? In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance. Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe.

Discussion:
Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use <del> when supplying them for individual connections.  Details about </del> <ins> when configuring PSKs for individual connections.  Details about </ins> existing stacks at the time of writing are below. OpenSSL and BoringSSL: Applications can specify support for

the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for <del> any operation.  When PSK identites are configured manually it is </del> <ins> any operation.  When PSK identities are configured manually it is </ins> important to be aware that due to encoding issues visually identical strings may, in fact, differ.

gnuTLS for example treats PSK identities as usernames. PSK identities MAY have a domain name suffix for roaming and <del> federation. </del> <ins> federation.  In applications and settings where the domain name suffix is privacy sensitive, this practice is NOT RECOMMENDED. </ins> Deployments should take care that the length of the PSK identity is sufficient to avoid collisions.

It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation <del> and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the </del> <ins> and sequencing of PSK callbacks influences the application's behavior when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the </ins> application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence