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

Nikos Mavrogiannopoulos <> Mon, 19 March 2018 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAE00126D3F for <>; Mon, 19 Mar 2018 06:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ffB_3GfKk4na for <>; Mon, 19 Mar 2018 06:33:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3AC91242F5 for <>; Mon, 19 Mar 2018 06:33:55 -0700 (PDT)
Received: by with SMTP id z12so18658783wrg.4 for <>; Mon, 19 Mar 2018 06:33:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=AlqpZ3goJWM8hZLCUPiFplLGx5V1OKOkG74v1knnvEI=; b=OdBujsshrpP4wuVIp4tVGd8zYDETLQOUR2yT9o+rKE/toldHXtBU50LU+oSqVXQUCF w5vtpTm572VTCZCSpFvEQ5Jkgbn9y8d9uGCWWcZ4Vn9GcvZV/BIR/mNn9Kdmd059FVCB xFGpVwIJwhYpZ8js/g+Ivl+NQRQPXaLHS3c1uPhN3ZkLaKurW+ta5QaTTXPqepJisgbp /nJzdG6RqrrFCVjSBuTmCcGOfMTTL08LTC8pkhpl+Sy7HTiXJGkMfEphMsN1Ad9RW2r4 PtYW/J3UCamwQWaDzOp9wU/ZnfW24+SUjQcPTvk75266ISZ4uW3/tIRpUkAc/Z9LrdYg uoIQ==
X-Gm-Message-State: AElRT7E8Z0wxLanYnKp7XhR5yjnwehxCJjSEGPt4EFK31KceRx2jOMea 4Ul8qfdbwB4JoAnsTi6ts/sfVg==
X-Google-Smtp-Source: AG47ELsBgyK2yOm4fyehity+vZNla6Ml3zw6DOfC16cQR/PsrlWEySclvBmCyo3doQtbZcah5s7SIw==
X-Received: by with SMTP id g52mr9868006wra.21.1521466434245; Mon, 19 Mar 2018 06:33:54 -0700 (PDT)
Received: from ( []) by with ESMTPSA id w29sm24147wra.84.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Mar 2018 06:33:53 -0700 (PDT)
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Benjamin Kaduk <>, Christian Huitema <>
Cc: TLS WG <>,
Date: Mon, 19 Mar 2018 14:33:52 +0100
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5 (3.26.5-1.fc27)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2018 13:33:59 -0000

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