Hi Jim, Thanks for the review. A clarifying question in-line.
On 7/2/20 12:02 AM, Jim Schaad wrote: > * 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. I think you are referring to the PSK identity and not to the PSK. As you know, the Network Access Identifiers (NAIs) used in EAP typically need the domain name suffix for roaming, federation, etc. I would like to understand the nature of the resulting privacy loss. Is it that a passive attacker can now easily determine the server which issued the PSK identity (and the server where it will eventually be used)? --Mohit > > * 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. > > Jim > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
