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

Benjamin Kaduk <> Fri, 16 March 2018 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EEB61252BA; Fri, 16 Mar 2018 12:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ad2tyQ4aOABc; Fri, 16 Mar 2018 12:45:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E325124217; Fri, 16 Mar 2018 12:45:26 -0700 (PDT)
X-AuditID: 1209190d-619ff700000022c0-3b-5aac1ed53868
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 5B.04.08896.5DE1CAA5; Fri, 16 Mar 2018 15:45:25 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w2GJjOBA014630; Fri, 16 Mar 2018 15:45:24 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w2GJjJSK002953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Mar 2018 15:45:22 -0400
Date: Fri, 16 Mar 2018 14:45:20 -0500
From: Benjamin Kaduk <>
To: Christian Huitema <>
Cc: Hubert Kario <>, TLS WG <>,
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTYRzHee5O92zs7DwVH2cKzZdAm2kZLSgNDBT/svxvQXW5p2263exu MxVBgzBYIZYFNiONpJmavQzCpKmsF9EsC5uIaflHRCoxkRAyle58/+/H7/N94XmBJOsK0UAL 78ACz1m1oSqKVUal6gLxnYb0to/R+onF1yH6hstNCn3j8g1SvzDiAsepvInGISqvtfUvkRfs DYQWkAbVUSO2WsqwsD/rnMrsuacr7U4ub+n9rqgBS/EuoISIyUR1I38IF1BBlnlAoK6rD0kZ sMwzgJ40a9ZBgEDzPWOEDCgmCU123QbyHMokoppro2uGSCYVdTZ9kzQQkkw+WrlbLK8jGIx8 H7xrVloqC3wd3Ch7TKDhpTlyHYSjwTs/KHkmmRQ0vjqzkROLPKtQXiuZbDQ5NqOQ5ygmAfnq /Ip6wLh3uN073O5tdwsg20Gc0Vaps3EWq4iLdGIRx/NY0B1Is1kcadjofA7WLjiG7garU/l+ wECgVdP6Tx0GNoQrEytsfhADCW0UnTMgrcLO240VZk40nxWcViz6AYKkNpJe/icx2shVVGLB voliIaWNpnMzUw0sY+IcuATjUixs0t0QahG9T3pUNlzAJlx+wWJ1bGMCKuVwtRSeLmtosZSz iRbTOh8CB+FP33QtCcd/zdWSLMXbeayJpgviJCkjS81OfitN/kKopK9qFkRLh4ugkRyolj7Y Vt6sVEVIVZYXbXKVg9tGmhpwuIGz79p7YmpkMdilL+Ru5hr+Zbs1R1TvL53u4JMv2uZ9wf7W xBInl7OHqO+hk6oWPrdbh7M8h441+b1Pz7x8O52gbi78cn8ljDwZ3l5QHFzx9GW8SmZPvelQ 4Yxc5ZXA5FJ1v1XxbuDRrUXyt3vUy3qqBwLXx4q9aZHdpmktJZq5jBRSELn/K9W7yx0DAAA=
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: Fri, 16 Mar 2018 19:45:29 -0000

On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > ...
> >> we do not have a reliable mechanism of differentiating between external and 
> >> resumption PSKs while parsing Client Hello
> > Well, a valid external PSK (identity) the server will of course
> > recognize, and we have a SHOULD-level requirement that the
> > obfuscated_ticket_age is zero for external PSKs.  I haven't gotten
> > to think through whether there is still potential for information
> > leakage about external PSK identities, but it seems like there would
> > not be, provided that the server prefers resumption to external-PSK
> > full handshakes.
> >
> I am concerned with the privacy issues linked to these "external PSK
> identities". If a system is set so that clients use static PSK
> identities, then the identity is an identifier and the client's
> movements and connections can be tracked. I don't think privacy is
> improved if we make it easy to differentiate external identities from
> resumption tickets.

Oh, of course, the privacy considerations of the current external
PSK scheme are terrible!  This follows naturally from external PSKs
having not really been a first-class citizen while we were designing
things; we stuffed resumption PSKs together with external PSKs for
the convenience of having them use the same binder construct and
only needing to have one extension at the end of the ClientHello.
Resumption flows get single-use tickets for privacy preservation,
and external PSKs get infinite use and a gigantic correlation

> If you want to use PSK with some level of privacy, you might adopt a
> different setup. For example, servers could provision the clients with a
> set of single-use external PSK identities. But then, that looks a lot
> like resumption. Or, clients could generate single-use external PSK
> identities by encrypting their long term identity and a nonce with the
> public key of the server, a design which of course has its own set of
> issues.

But, as you note, this is something of an open problem for how to do
well, and this document is already approved by the IESG.  (It's also
not entirely clear that the TLS WG would be the best place to design
this sort of scheme, though of course it could choose to do so.)

So to me the open question is whether we consider enumeration of
external PSK identifiers to be something we can address reasonably
at this stage of the document's lifecycle at all.  (I also note that
the presence of a CVE number for a similar issue does not
necessarily mean anything -- CVE assignments can occur for
situations with no actual security impact and/or against the wishes
of the software authors.)  I don't think anyone has proposed a
minimal change that would close the enumeration channel, and given
that external PSKs already have bad privacy properties, it seems
like we may just have to accept this state of affairs for this

Hubert also says:

% so there's no reliable way to say that, yes, this identity is or is not a
% resumption ticket, if I can't decrypt it

Mostly.  External PSKs are established out of band, and that
provisioning process *could* include knowledge that the
obfuscated_ticket_age would always be zero when those PSKs are in
use, and that would be reliable for those specific parties.

It's probably also worth considering the two cases for server
behavior when presented with a PSK id that is neither a known
external PSK nor a known resumption ticket -- the server could
either treat it as an unknown external PSK id or as a resumption
ticket that fails to decrypt.  The latter case fails because the
attacker can try candidate external identities and the server falls
back to a full handshake unless the PSK ID is good.  (Well, maybe
the server rejects PSK IDs that are shorter than a ticket would be.)
The first case is not really usable since it would lead to spurious
triggering of the proposed "at most one external PSK" check.

So, in addition to the "we provision external PSKs only when we know
that obfuscated_ticket_age will be zero", deployments could also
agree that external PSK ids are shorter than a given length and
resumption PSKs are larger, which would again provide a reliable
differentiator between resumption and external.

The privacy issues remain terrible, of course.

% I'd really prefer we exhaust other possibilities before sacrificing support
% for multiple external PSK. With TLS 1.2 we had ticket_hint to guide PSK
% selection, now we're left with just server IP or hostname.

I think that "do nothing and accept external PSK enumeration as a
risk" is more likely than sacrificing support for multiple external
PSKs, personally.