On Wednesday, 21 February 2018 15:31:33 CET Eric Rescorla wrote: > i think your general point is sound here, but I'll nitpick the statement > that > "if the server recognises an identity but is unable to verify corresponding > binder". > > 1. The server only picks one identity so you if you send A, B, and C and you > get an abort, you don't know if it recognized one or all. > 2. The server can *recognize* the identity but ignore it (say it's a ticket > that's > too old) > > With that said, I think it would probably be safe to say you must ignore an > identity > where the binder doesn't validate, but I'd like to hear from cryptographers > on this > one. Proposed https://github.com/tlswg/tls13-spec/pull/1167 so that we don't forget about it. > Thanks, > -Ekr > > On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario <hkario@xxxxxxxxxx> wrote: > > On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: > > > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario <hkario@xxxxxxxxxx> wrote: > > > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > > > > The IESG has received a request from the Transport Layer Security WG > > > > > > > > (tls) > > > > > > > > > to consider the following document: - 'The Transport Layer Security > > > > > (TLS) > > > > > Protocol Version 1.3' > > > > > > > > > > <draft-ietf-tls-tls13-24.txt> as Proposed Standard > > > > > > > > The current draft states that if the server recognises an identity but > > > > is > > > > > > unable to verify corresponding binder, it "MUST abort the handshake" > > > > > > Which text are you referring to here? > > > > Section 4.2.11: > > Prior to accepting PSK key establishment, the server MUST validate > > the corresponding binder value (see Section 4.2.11.2 below). If this > > value is not present or does not validate, the server MUST abort the > > handshake. Servers SHOULD NOT attempt to validate multiple binders; > > rather they SHOULD select a single PSK and validate solely the binder > > that corresponds to that PSK. > > > > > > -Ekr > > > > > > at the same time, they "SHOULD select as single PSK and validate solely > > > > the > > > > > > binder that corresponds to that PSK" > > > > (Page 60, draft-ietf-tls-tls13-24). > > > > > > > > That allows for trivial enumeration of externally established > > > > identities - > > > > > > the > > > > attacker just needs to send to the server a list of identity guesses, > > > > with > > > > > > random data as binders, if the server recognises any identity it will > > > > abort > > > > connection, if it doesn't, it will continue to a non-PSK handshake. > > > > > > > > Behaviour like this is generally considered a vulnerability: > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 > > > > > > > > I was wondering if the document shouldn't recommend ignoring any and > > > > all > > > > > > identities for which binders do not verify to prevent this kind of > > > > attack. > > > > > > -- > > > > 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 > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@xxxxxxxx > > > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > > 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 -- 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
