Re: [TLS] TLS1.3 + PSK with multiple identities

David Woodhouse <> Mon, 19 September 2016 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF03E12B404 for <>; Mon, 19 Sep 2016 08:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZP5ZB5BrXo_U for <>; Mon, 19 Sep 2016 08:38:05 -0700 (PDT)
Received: from ( [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CEDE12B3BD for <>; Mon, 19 Sep 2016 08:37:51 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] ( by with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bm0dg-0005Mp-G7; Mon, 19 Sep 2016 15:37:48 +0000
Message-ID: <>
From: David Woodhouse <>
To: Eric Rescorla <>
Date: Mon, 19 Sep 2016 16:37:45 +0100
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-NW3VlKmEIOrrhhCTqcrA"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24)
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <> by See
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] TLS1.3 + PSK with multiple identities
X-Mailman-Version: 2.1.17
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 Sep 2016 15:38:07 -0000

On Mon, 2016-09-19 at 07:55 -0700, Eric Rescorla wrote:
> > What if my client authenticates with an actual pre-shared key, and I
> > also want to resume a session? As it stands, that means I really do
> > need to offer two PSK identities — one for the real identity, and one
> > for the session resumption attempt. Are you saying that won't be
> > permitted?
> I should start by saying that it's not entirely clear why this is useful.
> Can you elaborate?

I should start by pointing out that I have no personal *need* for this;
it just seems strange and wrong to forbid it.

I assume you're not asking why one would use PSK in the first place, in
place of public keys? I think the introduction to RFC4279 fairly much
covers that and is still relevant.

So I interpret your question as asking why it's useful to *resume* a
session which was initiated with PSK?

Even though the cryptographic operations are basically the same —
there's none of the heavyweight asymmetric key operations, it's also
the case that resumed sessions may carry more application-specific
context than a newly-authenticated connection. 

Consider IMAP, as an example. It has a large amount of per-connection
state. This *could* be maintained even when the client disconnects —
you can imagine a mobile client which resumes an existing TLS session
and is *immediately* presented with all the status updates which have
occurred since it disconnected, without any need for re-building the
application-session state (or using any of the protocol extensions like
QRESYNC which help to reduce the connection startup time).

(Note: I'm not suggesting a *stateless* resume could do that.)

Perhaps I should turn your question round, and ask: if PSK is a first-
class citizen as a key exchange and authentication method, why *should*
we be forbidden from resuming sessions which started that way... just
because you've chosen to conflate PSK identities and session resumption
on the wire? :)

> > Or do we [need] to stop conflating the two types of PSK-identity, so that
> > we can allow only one of each?
> That doesn't address the reasons for only allowing one, unfortunately. See
> the thread on Finished stuffing.

OK, I'll read up on that; thanks.

> I would address this either by:
> 1. Registering a new extension which is used to indicate the right worker
> process, but using existing TLS 1.2 PSK.

OK... except this basically *is* the PSK identity. So the new extension
we'd want to register, if we want to make it something that's useful in
the general case rather than an application-specific hack, *is*
basically draft-jay-tls-psk-identity-extension :)

If we do anything else, we might as well stick with some of the horrid
hacks we already have (like abusing the session-id and not actually
*resuming* that session).

> 2. Wait for DTLS 1.3.

It's certainly *tempting* to manually add chacha20 to our ever-growing
list and *then* wait for DTLS1.3 :)