On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote: > The issue with the current draft is that it leaves a single PSK with > two potential interpretations. > If the draft also changed the PSK identity value then each PSK would > have a single interpretation. > If the draft changes the identity then it can also change the PSK key > without having to change the manner in which the binder is computed. > In that case universal PSKs and regular PSKs do not need to be > distinguished, because they are both validated in the same way. > > A server unaware of universal PSKs would simply see an unrecognised > PSK identity. > If both the unmodified and the modified PSKs are sent, then it can > simply select the unmodified version, ignoring the other. > A server that recognises both values can choose which to use. > > If the modified PSK identity was a channel binding, then the modified > version would have stronger security properties, and thus presumably > would be preferable. > In this case the hash function used for the binder remains > selectable. > > Would that resolve your issue?
That may not be sufficient. A server which sees an unrecognized PSK may chose to pretend it recognized it to avoid user enumeration attacks similarly to TLS1.2 (optional) behavior. Hence a modified username would cause negotiation failure with such a server. A new extension seems to be necessary to eliminate any interoperability issues with servers that will not follow the universal psk draft. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
