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

Commentary: cc 
 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 do n'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 do n'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 have n'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 .
Paragraph (version A):
Most major TLS implementations support external PSKs.  Stacks
supporting external PSKs provide interfaces that applications may use
when supplying them for individual connections.  Details about
existing stacks at the time of writing are below.
Paragraph (version B):
Most major TLS implementations support external PSKs.  Stacks
supporting external PSKs provide interfaces that applications may use
when configuring PSKs for individual connections.  Details about
existing stacks at the time of writing are below.
Paragraph (version A):
Section 5.1 of RFC4279 mandates that the PSK identity should be first
converted to a character string and then encoded to octets using UTF-
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
any operation.  When PSK identites are configured manually it is
important to be aware that due to encoding issues visually identical
strings may, in fact, differ.
Paragraph (version B):
Section 5.1 of RFC4279 mandates that the PSK identity should be first
converted to a character string and then encoded to octets using UTF-
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
any operation.  When PSK identities are configured manually it is
important to be aware that due to encoding issues visually identical
strings may, in fact, differ.
Paragraph (version A):
PSK identities MAY have a domain name suffix for roaming and
federation.
Paragraph (version B):
PSK identities MAY have a domain name suffix for roaming and
federation.  In applications and settings where the domain name
suffix is privacy sensitive, this practice is NOT RECOMMENDED.
Paragraph (version A):
It is possible, though unlikely, that an external PSK identity may
clash with a resumption PSK identity.  The TLS stack implementation
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
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
over how to handle the PSK.
Paragraph (version B):
It is possible, though unlikely, that an external PSK identity may
clash with a resumption PSK identity.  The TLS stack implementation
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
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
over how to handle the PSK.