After discussion with the chairs and the AD, I have opted to just add a section that explains the attack. I just merged that (but managed not to get it into -27 due to fumble fingering).
-Ekr On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario <hka...@redhat.com> wrote: > 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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
