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 Thursday, 22 February 2018 00:22:35 CET Martin Thomson wrote:
> I think that the current behavior is fine, but we might add text to
> suggest that identities be self-authenticating to avoid this sort of
> enumeration.  Note that in common practice, this sort of enumeration
> would be over an infeasibly large space, it's only where identities
> are more easily enumerable that it becomes an issue (e.g., "ted" as an
> identity, rather than a self-encrypted session ticket)

that's why the subject is saying "external PSK", and those can be as simple as 
"ted", "admin", "mary"...

yes, session tickets ("resumption PSK") SHOULD be self-authenticating, if only 
because non authenticated ciphertext is malleable

> On Thu, Feb 22, 2018 at 1:31 AM, Eric Rescorla <[e-mail]> 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.
> > 
> > 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