On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote: > 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...
not my fault that what we called just "PSK"s in TLS 1.2 is now "external PSKs" in TLS 1.3... I wanted to be unambiguous, so please, can we discuss the issue, not semiotics? > > 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. we do not have a reliable mechanism of differentiating between external and resumption PSKs while parsing Client Hello -- 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
