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

Christian Huitema <> Fri, 16 March 2018 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5916612706D for <>; Fri, 16 Mar 2018 06:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KXmnE0hrpuXU for <>; Fri, 16 Mar 2018 06:12:01 -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 59B3B1241F3 for <>; Fri, 16 Mar 2018 06:12:01 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1ewp9K-0004cf-UI for; Fri, 16 Mar 2018 14:11:59 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1ewp9F-00054j-VY for; Fri, 16 Mar 2018 09:11:55 -0400
Received: (qmail 14766 invoked from network); 16 Mar 2018 13:11:51 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 16 Mar 2018 13:11:50 -0000
To: Benjamin Kaduk <>, Hubert Kario <>
Cc: TLS WG <>,
References: <> <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Fri, 16 Mar 2018 09:11:32 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZLbt8mLnpkWpiuZJQGqUg4HYYe4TinvLf"
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5hPrUe1tpt2BJk/pAInVajd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxsnB4d6HfPmGuZRfkHfEqUEh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2OueuKdIJKegN3+UcLNo4xPvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbwyPr6Ygmqufq1En6WLLn AIHlTa0FG0ij7AOlTYklM4JccbCwAGyudfFnv3+d/9bREJuVuzej81SQVOLUKB0pbwwAhrb158v4 8tCoYG4Xx4Nz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAV8vAerBHKRzUHI5QDqE6Br1YE7tCqypI5WX0qWh4YQLC2JXAIdn+kbYpg P9VCenyhbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXIKl8biul71rKRjv1gUaCmQKHY 6H+wSCoVvwvquzDDiAluCSS51XoxcZ/6ctZTvvqYdub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
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 13:12:02 -0000

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.

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

-- Christian Huitema