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

Hubert Kario <hkario@redhat.com> Wed, 21 March 2018 13:46 UTC

Return-Path: <hkario@redhat.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 65A2E12D952; Wed, 21 Mar 2018 06:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 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, T_SPF_HELO_PERMERROR=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 EYzBZpnxPPie; Wed, 21 Mar 2018 06:46:45 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B33312EB86; Wed, 21 Mar 2018 06:46:38 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 343E6412A023; Wed, 21 Mar 2018 13:46:37 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 211637C3E; Wed, 21 Mar 2018 13:46:33 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Nikos Mavrogiannopoulos <nmav@redhat.com>, IESG <iesg@ietf.org>
Date: Wed, 21 Mar 2018 14:46:33 +0100
Message-ID: <4744920.YnLClJkS0m@pintsize.usersys.redhat.com>
In-Reply-To: <CABcZeBMxHQTmQnAkoukTbHwT1zWO69pA0c6v=bdWLCaidvK9Ag@mail.gmail.com>
References: <6112806.hxzZ6NivhB@pintsize.usersys.redhat.com> <3744627.MaMIWlZzZe@pintsize.usersys.redhat.com> <CABcZeBMxHQTmQnAkoukTbHwT1zWO69pA0c6v=bdWLCaidvK9Ag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2419910.Ptl9Jvinhn"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 21 Mar 2018 13:46:37 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 21 Mar 2018 13:46:37 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IsfjP-qJL5alCFfPJqpJ1uB851Y>
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: Wed, 21 Mar 2018 13:46:47 -0000

On Tuesday, 20 March 2018 22:21:06 CET Eric Rescorla wrote:
> 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.

ok, then I agree with those facts :)

-- 
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