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

Benjamin Kaduk <kaduk@mit.edu> Thu, 15 March 2018 21:52 UTC

Return-Path: <kaduk@mit.edu>
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 D4CAA126CC4; Thu, 15 Mar 2018 14:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sf35Wd3l2bee; Thu, 15 Mar 2018 14:52:01 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 21DAD1241FC; Thu, 15 Mar 2018 14:52:01 -0700 (PDT)
X-AuditID: 1209190f-dc3ff700000007c7-3c-5aaaeafee085
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 66.A4.01991.EFAEAAA5; Thu, 15 Mar 2018 17:51:59 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w2FLpsdh017828; Thu, 15 Mar 2018 17:51:56 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2FLpnQW000429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Mar 2018 17:51:52 -0400
Date: Thu, 15 Mar 2018 16:51:49 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Hubert Kario <hkario@redhat.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, TLS WG <tls@ietf.org>, iesg@ietf.org
Message-ID: <20180315215147.GP55987@kduck.kaduk.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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DO5DiztRLs659m5i"
Content-Disposition: inline
In-Reply-To: <1937539.vLgMNW4b7C@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRmVeSWpSXmKPExsUixG6novv/1aoog4MrxSxufTvMajHjz0Rm i/e7p7NYfDrfxejA4rFkyU8mj/f7rrJ53O6ewxbAHMVlk5Kak1mWWqRvl8CVMaV1F3PBRumK Q+1zWBsYz4l1MXJySAiYSPS27WTpYuTiEBJYzCSx/cdGKGcjo8TvT1vZIZyrTBJ3z95gBmlh EVCVeP7jASOIzSagItHQfRksLgJknz3VCWYzC8RKXDn9ghXEFhZIldh7djMTiM0LtO7hvlVs EEPPMkrM3L2HESIhKHFy5hMWiOYyiRfrXgIVcQDZ0hLL/3GAhDkFbCV+z10MViIqoCyxt+8Q +wRGgVlIumch6Z6F0A0R1pK48e8lE4awtsSyha+ZIWxbiXXr3rMsYGRfxSibklulm5uYmVOc mqxbnJyYl5dapGuil5tZopeaUrqJERQlnJL8OxjnNHgfYhTgYFTi4c1oXhUlxJpYVlyZe4hR koNJSZS3oxwoxJeUn1KZkVicEV9UmpNafIhRBWjXow2rLzBKseTl56UqifD6PwOq401JrKxK LcqHKZPmYFES53U30Y4SEkhPLEnNTk0tSC2CycpwcChJ8DoBk4SQYFFqempFWmZOCUKaiYPz EKMEBw/Q8EiQGt7igsTc4sx0iPwpRmOOZ3sftDFz3Hjxuo1ZCOwOKXFeX5BSAZDSjNI8uGmg BCiRvb/mFaM40KPCvJ0vgap4gMkTbt4roFVMQKsyt60AWVWSiJCSamCUdT3kIFDK4lTDv11N zC3om17Hl/IT3aFmCranQj4+3KpkVHL9aqHPuurmzd7zP/5vOXE//XvjTk4zrqjZ5oIV/82+ dwV+ffBvwrLzAVxHoxNdnZb/ZGcP2Ox10eLYx/lRm/m1ZA+VJy60zvNeHDRz6vej0n2vkxM1 ds97pime5Xwn4n87j74SS3FGoqEWc1FxIgCVDxteWwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LakaUN6GlyReVhvBgPoCJsy4pTQ>
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: Thu, 15 Mar 2018 21:52:03 -0000

On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote:
> > On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote:
> > > On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote:
> > > > It seems like we get ourselves in trouble by allowing multiple
> > > > external PSKs to be present.  If we allowed at most one external
> > > > PSK in a given ClientHello, then aborting the handshake on binder
> > > > failure would be the correct choice, as discovering a valid identity
> > > > would require discovering a valid key/password as well.
> > > 
> > > but identity/binder may be invalid only because the server was restarted
> > > and generated a new in-memory key; we don't want to abort connection in
> > > such
> > For an external PSK?  That hardly sounds like "external" to me...
> 
> not my fault that what we called just "PSK"s in TLS 1.2 is now "external PSKs" 
> in TLS 1.3... I wanted to be unambiguous, so please, can we discuss the issue, 
> not semiotics?

Sure!  (I still don't see how an ephemeral in-server key would be
used as/with an external PSK.)

> > > situation, continuing to a regular handshake is necessary then for good
> > > user experience (and likely, even security, given the history of TLS
> > > version fallbacks)
> > > 
> > > > Disallowing multiple external PSKs would make migration scenarios a
> > > > little more annoying, but perhaps not fatally so.
> > > 
> > > not only migration, but session resumption and regular PSK at the same
> > > time
> > > too - for session resumption you may not do DH, while for initial
> > > handshake
> > > with PSK you may want to to gain PFS...
> > > 
> > > so as tempting as the removal of multiple PSKs from ClientHello is, I'm
> > > afraid the fallout is far too large to do it
> > 
> > I did not say removal of multiple PSKs, rather removal of multiple
> > *external* PSKs.
> 
> 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.

-Benjamin