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

Benjamin Kaduk <kaduk@mit.edu> Mon, 19 March 2018 23:01 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 BC53512D7EF; Mon, 19 Mar 2018 16:01:58 -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 AqJqohZeCH_0; Mon, 19 Mar 2018 16:01:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 089F712AF84; Mon, 19 Mar 2018 16:01:55 -0700 (PDT)
X-AuditID: 12074422-1e5ff70000003c13-c2-5ab0415fb5fd
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.D4.15379.16140BA5; Mon, 19 Mar 2018 19:01:54 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w2JN1lfc014467; Mon, 19 Mar 2018 19:01:49 -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 w2JN1hIY020710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Mar 2018 19:01:46 -0400
Date: Mon, 19 Mar 2018 18:01:43 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: Christian Huitema <huitema@huitema.net>, TLS WG <tls@ietf.org>, iesg@ietf.org
Message-ID: <20180319230141.GQ55745@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> <20180315215147.GP55987@kduck.kaduk.org> <c7427ccf-51fc-235d-4555-a0c3d7d6f846@huitema.net> <20180316194519.GZ55987@kduck.kaduk.org> <1521466432.30491.16.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1521466432.30491.16.camel@redhat.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT101y3BBlcHuyiMXkxtnsFjP+TGS2 +HF0K4vFp/NdjA4sHrdmnGLxWLLkJ5PH+31X2QKYo7hsUlJzMstSi/TtErgyWrdMZinYrlXx 7/RK9gbGtYpdjJwcEgImEocWzWXuYuTiEBJYzCTxYv4OdghnI6NEW2sblHOVSeLVyvuMIC0s AqoSz9uOMYPYbAIqEg3dl8FsEQFdiUvNT9lBbGaBKIm5+2+wgtjCAqkSe89uZgKxeYHW3f/w jRFiaCOzxJ7+O+wQCUGJkzOfsEA0a0nc+PcSqIEDyJaWWP6PAyTMKWAscWDrabBdogLKEnv7 DrFPYBSYhaR7FpLuWQjdCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRuYgSH sYvSDsaJ/7wOMQpwMCrx8GrcWR8lxJpYVlyZe4hRkoNJSZT3FNOGKCG+pPyUyozE4oz4otKc 1OJDjBIczEoivE+vrIsS4k1JrKxKLcqHSUlzsCiJ83qYaEcJCaQnlqRmp6YWpBbBZGU4OJQk eAsdgIYKFqWmp1akZeaUIKSZODhBhvMADb9nD1TDW1yQmFucmQ6RP8VozPFs74M2Zo4bL163 MQux5OXnpUqJ8/qClAqAlGaU5sFNA6Uiiez9Na8YxYGeE+Z9CVLFA0xjcPNeAa1iAlrls3QN yKqSRISUVAOj7rS2WZMqzzY8ncyxp/O3sq/R7C1CgU7qrv6rDeYwPVkjaXPons2cs+5q6fy/ ZyedNJeMVpb75cSt9okjuMu5aGG30p2PknH7tXetumqnKNbOy97iuXhvT/+KhDL+m0fOrmb7 4f1y/fKcn/UvHQT5tu1rc9i/8MWOZan/I/+3+zse/2ZVMkFGiaU4I9FQi7moOBEAmvj2nCAD AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ix0sq2kied50z43ZZmBfX1nLnLE>
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: Mon, 19 Mar 2018 23:01:59 -0000

On Mon, Mar 19, 2018 at 02:33:52PM +0100, Nikos Mavrogiannopoulos 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:
> > > 
> > 
> > > 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.

I think you are just referring to the bit about CVE numbers not
necessarily indicating much of anything?

I would like to hear your opinion on the "open question" I
identified...

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

The convention for PSK-only deployments in the text Ekr added seems
clear enough to me, so it seems that only deployments willing to do
either Certificate or PSK in the same server instance are at risk.

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

You think there will be a server using resumption PSK identifiers
shorter than 128 bits??

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

Especially in light of subsequent updates on the thread, this does
not seem to be a strong enough argument to merit a change after IESG
approval.  There seem to be some options for future updates in
backwards-compatible ways, in any case.

-Benjamin