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

Christian Huitema <huitema@huitema.net> Fri, 16 March 2018 13:12 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5916612706D for <tls@ietfa.amsl.com>; Fri, 16 Mar 2018 06:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXmnE0hrpuXU for <tls@ietfa.amsl.com>; Fri, 16 Mar 2018 06:12:01 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B3B1241F3 for <tls@ietf.org>; Fri, 16 Mar 2018 06:12:01 -0700 (PDT)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ewp9K-0004cf-UI for tls@ietf.org; Fri, 16 Mar 2018 14:11:59 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ewp9F-00054j-VY for tls@ietf.org; 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 [10.0.0.17]) (Authenticated-user:_huitema@huitema.net@[24.139.245.142]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <iesg@ietf.org>; 16 Mar 2018 13:11:50 -0000
To: Benjamin Kaduk <kaduk@mit.edu>, Hubert Kario <hkario@redhat.com>
Cc: TLS WG <tls@ietf.org>, iesg@ietf.org
References: <6112806.hxzZ6NivhB@pintsize.usersys.redhat.com> <2062943.8cTCpni5Dm@pintsize.usersys.redhat.com> <20180314201328.GF55987@kduck.kaduk.org> <1937539.vLgMNW4b7C@pintsize.usersys.redhat.com> <20180315215147.GP55987@kduck.kaduk.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <c7427ccf-51fc-235d-4555-a0c3d7d6f846@huitema.net>
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: <20180315215147.GP55987@kduck.kaduk.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZLbt8mLnpkWpiuZJQGqUg4HYYe4TinvLf"
X-Originating-IP: 168.144.250.215
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
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=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XW_6HNAN-61qgLBqtrghgQLwpEM>
Subject: Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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
issues.

-- Christian Huitema