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

David Woodhouse <> Mon, 19 September 2016 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1CD512B0B9 for <>; Mon, 19 Sep 2016 05:33:24 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wi29eAvZgWCp for <>; Mon, 19 Sep 2016 05:33:21 -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 DCC3112B373 for <>; Mon, 19 Sep 2016 05:26:47 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] ( by with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1blxen-0005bU-GB; Mon, 19 Sep 2016 12:26:45 +0000
Message-ID: <>
From: David Woodhouse <>
To: Eric Rescorla <>
Date: Mon, 19 Sep 2016 13:26:42 +0100
In-Reply-To: <>
References: <> <> <> <> <>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-OYRZN9qGmSKI6TGAwQe/"
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 12:33:25 -0000

On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > Do we care that the '0x00 0x12' bytes on my third line above are
> > entirely redundant on the wire? Or have I interpreted it wrong?
> Not enough to fix it, this is just the way TLS rolls.

An interesting contrast to Nikos's observation that using the index in
the response is "used nowhere else in TLS" — which he could have
phrased using similar words. But I suppose in that case you're saving a
*lot* more than two bytes in the ServerHello, so it makes sense to
deviate from "the way TLS rolls" :)
> > Is there no way the PSK identities for session resumption could be made
> > smaller? Of the data which RFC5077 suggests that we put into a session
> > ticket (and thus the PSK identity), is there *none* of it which could
> > be sent later in a ClientKeyExchange packet? 
> No. Also, there isn't a CKE record in TLS 1.3. All information needed to derive
> the key needs to be in the CH.

Well, that was kind of my point. Information needed to derive the *key*
needs to be in the ClientHello.

But if it's auxiliary information which isn't actually *needed* to
derive the key or to select which {identity to use,session to resume},
then perhaps the client could be required to supply it afterwards.
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.

But OK, if none of the information included by RFC5077 is in that
category then we really do need to cope with PSK identity fields which
can theoretically *each* be larger than the amount you can fit into a
single TLS extension...

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. And
the binary nature of 'session resumption' PSK identities will have an
effect on the crypto library APIs used to manage that — which as I
said, currently assume that they can use NUL-terminated strings.

So it would be useful to have some clarity on the UTF-8 requirement
from RFC4279, and whether it's being completely abandoned with TLS 1.3.

> > Is it permitted, and what is the meaning, to request a cipher suite of
> > (e.g.) TLS_PSK_WITH_AES_256_CBC_SHA and set PskKeyExchangeMode in the
> > identity to 'psk_dhe_ke'? Or conversely, to use the cipher suite
> > TLS_DHE_PSK_WITH_AES_256_CBC_SHA with PskKeyExchangeMode set to
> > 'psk_ke'?
> > 
> > This seems redundant to me at first glance (unless some combinations
> > really do mean that you end up doing DHE *twice*) and could probably do
> > with some clarification.
> TLS 1.3 cipher suites do not convey key exchange mode, just AED and KDF. See
> for an overview of
> negotiation.

Ah, thanks. That makes more sense now.