On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote: > On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote: > > It seems like we get ourselves in trouble by allowing multiple > > external PSKs to be present. If we allowed at most one external > > PSK in a given ClientHello, then aborting the handshake on binder > > failure would be the correct choice, as discovering a valid identity > > would require discovering a valid key/password as well. > > but identity/binder may be invalid only because the server was restarted and > generated a new in-memory key; we don't want to abort connection in such
For an external PSK? That hardly sounds like "external" to me... > situation, continuing to a regular handshake is necessary then for good user > experience (and likely, even security, given the history of TLS version > fallbacks) > > > Disallowing multiple external PSKs would make migration scenarios a > > little more annoying, but perhaps not fatally so. > > not only migration, but session resumption and regular PSK at the same time > too - for session resumption you may not do DH, while for initial handshake > with PSK you may want to to gain PFS... > > so as tempting as the removal of multiple PSKs from ClientHello is, I'm > afraid > the fallout is far too large to do it I did not say removal of multiple PSKs, rather removal of multiple *external* PSKs. -Ben(jamin) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
