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 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 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
