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

David Woodhouse <> Mon, 19 September 2016 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D8BE12B15D for <>; Mon, 19 Sep 2016 07:08:03 -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 gg-TF366yiHZ for <>; Mon, 19 Sep 2016 07:07:59 -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 2DA2C12B04E for <>; Mon, 19 Sep 2016 07:07:59 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] ( by with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1blzEi-0003td-CF; Mon, 19 Sep 2016 14:07:56 +0000
Message-ID: <>
From: David Woodhouse <>
To: Eric Rescorla <>
Date: Mon, 19 Sep 2016 15:07:53 +0100
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-JOFQwjB5VR/k5eAgutDy"
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 14:08:03 -0000

On Mon, 2016-09-19 at 05:46 -0700, Eric Rescorla wrote:
> > And then the client only needs to supply one copy of it for the
> > identity which the server actually selected, not one for *each*
> > identity which was being offered by the client.
> We're most likely going to allow only on PSK anyway.

You mean "only one", I assume?

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

Or do we stop to stop conflating the two types of PSK-identity, so that
we can allow only one of each?

> > I share Nikos's concern about using the PSK identity for two completely
> > different types of identifiers — especially given that one type has
> > historically been defined as UTF-8 text, while the other is binary.
> > 
> > The reason I care about this right now is that we're looking at using
> > PSK to bootstrap a DTLS connection in the context of an SSL VPN,
> > currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension.
> I recommend against this: I very much doubt that we are going to adopt this
> draft in TLS.

That is useful feedback; thank you. Although I'm slightly confused —
although the draft is out of date, I thought the point of it was to
simply document what you *are* adopting in TLS1.3, for use in TLS1.2.
Are you saying that the extension will never be retroactively 'blessed'
for TLS1.2 even when it's part of TLS1.3?

What we're trying to do is move away from the existing model, inherited
from Cisco AnyConnect, where the DTLS ciphersuite is negotiated out-of-
band along with a master secret, and then we 'resume' a DTLS session
that never really existed.

It took us a *long* time to gain support for DTLS1.2 and AEAD cipher
suites because of that, and it would be much better just to let DTLS
negotiate as $DEITY intended.

But the architecture of our server is such that it *really* wants to
know from the very first ClientHello packet which client it's talking
to, so that the packet can be dispatched to the correct worker

The first prototype of this continued to abuse the Session-ID to
identify the client — making it *look* like a session resume attempt
when in fact we weren't prepared to resume the session at all, and we
rely on the server *not* doing so.

I kind of threw my toys out of the pram at that — if we're going to
attempt to use the protocol properly, then I really do want to do it
*properly*. Hence the interest in draft-jay-tls-psk-identity-extension.

If that's not going to be viable, then I'm starting to wonder if we
should just wait for DTLS1.3. After all we *already* support the fun
parts of DTLS1.2, and AEAD ciphersuites, so there's no desperate rush
to start using proper negotiation.