Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Hubert Kario <[e-mail]>]

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 <[e-mail]> wrote:
> > On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
> > > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario <[e-mail]> 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
> > > > [e-mail]
> > > > 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