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

Eric Rescorla <> Mon, 19 September 2016 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B64012B3A6 for <>; Mon, 19 Sep 2016 05:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aq2TyyTyhmt4 for <>; Mon, 19 Sep 2016 05:48:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C588E12B3EC for <>; Mon, 19 Sep 2016 05:46:50 -0700 (PDT)
Received: by with SMTP id t67so142015889ywg.3 for <>; Mon, 19 Sep 2016 05:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSUSFOFmhnaYYjf4CwATJ2Pyt3ZYCaqJq8OrV5MxdzU=; b=0ec5MP9YQNVoO6Rigdrfm7ZDpexGVufu6HUO2gm0j63qB8jUEXgo0pAgcC9bVbKHHn /rPuDY+bMK+1kLskSn/72koQYG8GxscQkRSIHJ81ffqMpWfy25/A3b6HNWzIdZi6PUQ6 q8l6UNXV58VQluhW8233kIZlUBCj+JGoAhG0OSowD7NjU0XOh8qocrkBy+5gWoEowiAk 7QdQ5oyCM1sDOkgCVXUemMKrsmA9xS8102XazNizZ0csVqncfrPgwJ6LaZreSmM2sWhv MdUzoQ9aQa0cKnN4qxhf7ISyiH538ONFTsocGA5x3aQMTjnFIIEHu2dRqgssaJJ3k+Fv geNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSUSFOFmhnaYYjf4CwATJ2Pyt3ZYCaqJq8OrV5MxdzU=; b=iKYVz+VFEuJ+eB7imZupne1n+DvRtMItnmN8HF5JTwCqmw4LL67M3rbv5uBu5Yj1xN e8VP0HX5xPzGnBMUJHmGYCrWkT7kNIohUwDP7axNXAowKimL3WIeNGvOPGe3P6RrcJnx ycrpuH6O8mjsZyfzLsClHFuI6PchAfANr4AKA+ICBD/7hBmFy7lNB6Hqfzs5NxDFkCyG UwXug6m7BNq8l+jInrJa8/dlbvl+7QBcieeF7IYoRqsxoLQmxuTrv8cZAxTSOBKQzF89 JPOx9hnlJcO+5+FEp2QoSV2ivdZ7iCXuIHUfF03RsqQZcEIpi8Cj8oj879pXqB0bWMFH JR9A==
X-Gm-Message-State: AE9vXwPtnStNGDUXWEaY+BMQzqVo09WDASystIplR99TTRVKRvTSK3mUePVrpmAW34bzcjQrmEBMB8XDvI0hIw==
X-Received: by with SMTP id h184mr25710788ywb.52.1474289210067; Mon, 19 Sep 2016 05:46:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Sep 2016 05:46:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 19 Sep 2016 05:46:09 -0700
Message-ID: <>
To: David Woodhouse <>
Content-Type: multipart/alternative; boundary=001a114d6f1ca9bd38053cdbb4f4
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:48:22 -0000

On Mon, Sep 19, 2016 at 5:26 AM, David Woodhouse <>

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

You need the complete ticket to make sensible decisions.

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.

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.

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.

It's being abandoned. PR welcome.