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

For externally established PSKs (especially for IoT devices) the identity can be as simple as a serial number, easily enumerated. I think it would be a mistake to place requirements on the structure of the identity to resolve this (if it needs resolving); IMHO treating the situation in the same way as one which does not include a valid PSK is better. But I agree with Eric that we should hear from cryptographers on this.
-- Tony

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: 21 February 2018 23:23
To: Eric Rescorla
Cc: draft-ietf-tls-tls13@ietf.org; <tls@ietf.org>; IETF discussion list
Subject: 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

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)

On Thu, Feb 22, 2018 at 1:31 AM, Eric Rescorla <ekr@rtfm.com> 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@redhat.com> 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@redhat.com> 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@ietf.org
>> > > 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
>
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.