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 <ekr@xxxxxxxx> 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 <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 RepublicAttachment:
signature.asc
Description: This is a digitally signed message part.
