Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
Eric Rescorla <ekr@rtfm.com> Tue, 20 March 2018 21:21 UTC
Return-Path: <ekr@rtfm.com>
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 0096F129C59 for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 14:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 al57ZuFrC8sQ for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 14:21:48 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76BE129BBF for <tls@ietf.org>; Tue, 20 Mar 2018 14:21:47 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id o184so3329986qkd.13 for <tls@ietf.org>; Tue, 20 Mar 2018 14:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UZu+J4DhFECr6mi4dTIpqEOvRo8HqU1WhN76GzGJTck=; b=QbvSi3edHD0JbpFDA7i0gvnnEdLiNp1Sj6b1ZsZsFwAMZqiWHCFvTgbKTtt24gQrQ+ 6yzNspw/BNyyPz2BEXmwZVrHhg6lEPYC953MB61dtV5Dr7PdcosoklXWxO1R+jpZ4KrP ECgC+z4wQ/+X4iqINonY+Z1E+5eMgGjHOsqg0CCe/keLxP0xRsx4dKm0PNVYAWKeR93N YpFUAYGywtrr9iNsNRJ5Fw5ZPT/b83C0RaMkAIKODQ9hG8F8dOEDE+odxO+/3D054Gsd qFwILlR8bMxg0owOODSATR7w2qp2mqJnkeh11oZJ0URAAK0IP0fXIvOm3z4pRDB+c0P/ 4ZWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UZu+J4DhFECr6mi4dTIpqEOvRo8HqU1WhN76GzGJTck=; b=TKxlcGuSkokfMr4i5JTfWPAyt+N8XaFQeioeadj3J/RsNj4JOYTNlGpT3tzfkzzdWX WwumBgfTT7COcw0WiPt+HxDjnoeC/YnbwMeRQyzHUqt2bUM2k1VcSAkmTiGIh4aFLzve 0lYdjW78L+Y4d/E6rZLBIVNIp9OS1O+GwXwxbM67YjLZHPUBO1Iql1mfavuVJzedrQL6 3d69WQrTYIQDrDJTU3ykYyBLzdHBtPuJ4LT/Azz8pTQupR3Qx/hT4lri0QYiDzQbqKln MP9vKKqxneWx0EybqKv2hIVYvqLxp/RgIO2a/riA+YpUbzKTLpB45SCvTP8l4lO8A7m9 d5hw==
X-Gm-Message-State: AElRT7Fd53zOAIBvpEQfsWzkcukJ7Kkr3neIQyqkc7puX0qHvftGKRhn 0tCKPQQtDSWjZEW5PzEnct55j42I4MUeCMor78jY+A==
X-Google-Smtp-Source: AG47ELvbTtgCqT/fSfMLpA+4BFij+nfsasMvbOHQMgFovkrCxE0R5I3MzZrNz17PTbTr04KErMuxARZDh/fzTmdke/Q=
X-Received: by 10.55.23.101 with SMTP id i98mr26175742qkh.91.1521580906508; Tue, 20 Mar 2018 14:21:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.234 with HTTP; Tue, 20 Mar 2018 14:21:06 -0700 (PDT)
In-Reply-To: <3744627.MaMIWlZzZe@pintsize.usersys.redhat.com>
References: <6112806.hxzZ6NivhB@pintsize.usersys.redhat.com> <1521466432.30491.16.camel@redhat.com> <CABcZeBPThERW6NnOKkTZ7gxPpq+7Xno+7nEkLr612kt_7FcHEw@mail.gmail.com> <3744627.MaMIWlZzZe@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 20 Mar 2018 21:21:06 +0000
Message-ID: <CABcZeBMxHQTmQnAkoukTbHwT1zWO69pA0c6v=bdWLCaidvK9Ag@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Nikos Mavrogiannopoulos <nmav@redhat.com>, IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e91646e096b0567dea91f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xrKcw5YrqU6ypunZM1gqx4xs96g>
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: Tue, 20 Mar 2018 21:21:52 -0000
On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario <hkario@redhat.com> wrote: > On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote: > > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos < > nmav@redhat.com> > > > > wrote: > > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote: > > > > 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 > > > > channel. > > > > > > I agree. > > > > > > > > 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 > > > > document. > > > > > > That's a good general remark, but not really the case for the > > > vulnerabilities that Hubert pointed out. > > > > > > > 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. > > > > > > I believe that this can happen in an interoperable way if the protocol > > > mandates it (which is not the case now). These specific parties may use > > > software from different vendors which may use different conventions if > > > the protocol is not clear enough. > > > > > > > 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. > > > > > > That cannot easily happen. I can have multiple servers answering to the > > > same hostname each using a different implementation. Any conventions > > > used in one implementation would not apply to another. > > > > > > > % 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. > > > > > > The problem is that you personally are not affected by that risk and I > > > guess that makes it easy for you to accept it. TLS1.2 with PSK did > > > explicitly prevent enumeration (by asking implementations to proceed to > > > handshake even with unknown usernames, and making up a key), meaning > > > that this is a risk that the designers of PSK (external) intentionally > > > ruled out. Going that path, it would be a step back in PSK security for > > > TLS1.3. > > > > Nikos, > > > > Just as a clarification, I believe it's possible for a PSK-only > > implementation to > > avoid this attack by behaving uniformly for "unknown ID" and "invalid > > binder" > > supporting both external PSK authentication and certificate based > authentication for a single IoT gateway would be quite expected, I'd say > > so just because PSK-only implementations are not vulnerable, I don't think > we > can expect all servers that deploy external PSKs will also disable > certificate > based authentication (not to mention that it's rather unlikely that users > will > expect that adding certificate will suddenly make their server vulnerable) I'm not making an argument, I'm merely stating what I believe to be the facts. -Ekr -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic >
- [TLS] draft-ietf-tls-tls13-26 is vulnerable to ex… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Ilari Liusvaara
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Christian Huitema
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Lanlan Pan
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Daniel Kahn Gillmor
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Joseph Lorenzo Hall
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Sean Turner
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Kathleen Moriarty
- Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable t… Hubert Kario