[TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario <[e-mail]>]

When the server supports externally set PSKs that use human readable 
identities (or, in general, guessable identities), the current text makes it 
trivial to perform enumeration attack.

The proposed fix was identified as conflicting with the "Client Hello 
Recording" security section, the severity of that conflict wasn't quantified 
though.


Issue in detail:

Problematic paragraph as it stands in draft-ietf-tls-tls13-26 (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.  In order to accept PSK key
   establishment, the server sends a "pre_shared_key" extension
   indicating the selected identity.

That means, given a server with both PSK and PKI authentication, if attacker 
sends multiple PSK identities with garbage binders, the server will abort the 
connection if and only if at least one of the identities was recognised by 
server. Applying the well known binary search method allows the attacker to 
then narrow it down to a single identity in O(log_2(n)) steps.

The solution to ignore that one selected binder, and continuing the connection 
in case that binder does not validate (this is the version in the PR mentioned 
below), unfortunately doesn't solve this issue either;

If the attacker is in possession of a known good PSK secret (established 
either through session resumption mechanism or of a less-privileged identity), 
it can list the known good one as the very last one in the PSK extension. If 
server recognises one of the identities earlier in the list it will choose no 
identity (as the binder didn't validate) or the known good identity if none of 
the previous identities were recognised. Again, applying binary search method 
allows the attacker to narrow the list to a single entry in just O(log_2(n)) 
steps.


Proposed solution:

in paragraph above, in description of `binders`:
  binders
  : A series of HMAC values, one for
   each PSK offered in the "pre_shared_keys" extension and in the same
   order, computed as described below. If the number of binders does not match
   number of identities the server MUST abort the connection with
   "illegal_parameter" alert.

problematic paragraph after changes:
   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value does not validate, the server MUST ignore the
   associated identity and retry selection of identity. If no identity is 
   recognised or, for recognised identities, no binder could be validated
   the server MUST continue connection as if PSK key establishment wasn't
   attempted.  In order to accept PSK key
   establishment, the server sends a "pre_shared_key" extension
   indicating the selected identity.

Unfortunately that solution was identified as conflicting with "Client Hello 
Recording" section.

Do we consider that conflict to be severe enough to block this change?

Or should we just add more information to that security section, that it needs 
to deal with this kind of attack?

PS: some discussion on this issue already happened in the github PR: 
https://github.com/tlswg/tls13-spec/pull/1167
-- 
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