Given that channel bindings are generally the output of a hash transcript there seems to be minimal risk of PSK enumeration. If I send a PSK that the server recognises, alongside one it does not, would a server sometimes pretend to accept the PSK it does not recognise to avoid enumeration attacks? That behaviour would seem strange to me.
If it's only the behaviour when all PSKs are unrecognised then this shouldn't be an issue if the unmodified PSK is sent as a less secure fallback option. If all PSKs including the unmodified one are unrecognised then negotiation failure is the correct response. On the other hand, I have no objection in principle to an extension. Regards, Jonathan On Mon, 18 Jun 2018 at 14:18 Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > 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
