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

Eric Rescorla <> Sun, 18 March 2018 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88CC61270AC for <>; Sun, 18 Mar 2018 08:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 26bvR1c5lXJp for <>; Sun, 18 Mar 2018 08:28:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E878F12D87A for <>; Sun, 18 Mar 2018 08:28:15 -0700 (PDT)
Received: by with SMTP id z184so15898931qkc.1 for <>; Sun, 18 Mar 2018 08:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MoJuLrkVAu+iq0j+sN85O+dZ0WRwLBJE7dUJ4u9mu54=; b=Pqniw3PLg7J6gpokknKtZE/Ao40fQbS9QLAi3TqsCJClooMUFJeV+Cj3gyr3Vaa0SS pdHBlzuTotFk2T97YRHhas8PbG/z5flJ5XWwaiOGFIiv1Qyldfn8ObulvbOhSFXxEnk4 dQSaLgm4BoZOMSgMkd75Wtz7VxzUUJBgjwALwO2qm7OliWbkUXs+rOOqXXdC/t0LVOvf I0U6B1FjxwcL+QnZ6OfkiFD+C/LgTD3dHtc2OAeFaMTFV0Bm59LZhjPrTVyUeFHN/Dh/ tU5wE5G7/TuYc+Ady7Zwc3cPmgDc/K2/VuLER85bs+E0Y7zORvgTptgEFZV4ZKAm9/Vz RivQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MoJuLrkVAu+iq0j+sN85O+dZ0WRwLBJE7dUJ4u9mu54=; b=dDbnsDn00M4mJW5fSnIHMMqZfGy1amBq47yoSZI7uErHCW21ixiNhXju/SFhabIMbN QQEj1FBNcpPvYa+AzifJn3cS4zT6+XLax+wcgoKUY4pbfCvWPwRmzVXVxi5LU4Lufz2Y 4xW+1rSR1qk6KkHeZe3KTcfQiaJzw3oukwKZXCiNcTfG5HU5r8biLuxcg8DpW0LfhbmC lBmn8b2pXyEJcHKbk/2kyQNcQXI4LdpG+XlyA4thUqB13we6zvGZ3fgppBIGWzDpmECw D4SIJUL1jsB0vc8k8E9RZljERZBk1t/csDDC+aybBSz0y/agx6Uknj6fCLuR9bnr14pF FBpw==
X-Gm-Message-State: AElRT7E+M2BeyGkIvvOmbL71GrV6OM00iAYIxQ8U7Zi8kyl09tuJAz37 6qpgI+K7W2afIAb885sySxmvmj8c48RTYv0+vnTb/w==
X-Google-Smtp-Source: AG47ELv/RDwYehGfEw2sN+h/YTCRx3fEwj8yDIOD14SB/c3nCF9TeBGF5wYuJlvS5FAms5MlrObPKKxm6QPS9RUZfBI=
X-Received: by with SMTP id n7mr13478878qkb.15.1521386894987; Sun, 18 Mar 2018 08:28:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 18 Mar 2018 08:27:34 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Sun, 18 Mar 2018 15:27:34 +0000
Message-ID: <>
To: Hubert Kario <>
Cc: TLS WG <>, The IESG <>, tls-chairs <>
Content-Type: multipart/alternative; boundary="001a114c91aa712c740567b17db2"
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Mar 2018 15:28:28 -0000

After discussion with the chairs and the AD, I have opted to just add a
that explains the attack. I just merged that (but managed not to get it
into -27
due to fumble fingering).


On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario <> 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 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 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:
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web:
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> _______________________________________________
> TLS mailing list