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

Eric Rescorla <> Mon, 19 September 2016 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4290C12B417 for <>; Mon, 19 Sep 2016 09:54:40 -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 CGtbzByjcHbA for <>; Mon, 19 Sep 2016 09:54:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 550E712B13A for <>; Mon, 19 Sep 2016 09:54:38 -0700 (PDT)
Received: by with SMTP id g192so158583660ywh.1 for <>; Mon, 19 Sep 2016 09:54:38 -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=Xfl8M7vFIScIOdwvVhvTHTdsUpHmN+t2BLyg1IrXs2U=; b=vjHjUn/+5p1w6ZyUJS8nsWycVRbDkPu5e5cvDUPPq4+SRaRSqlsouOYWWzKXJOj2zH afGbAY695ubcnuicMOeK5OCSCYFo+ll4cAmNK65xHGx4/2V4/sUGM/t2fr2WUvJWPIOf sEv3rHfpU17Ui8+l+xlaYQ8u1cM2UisloOav8B6ndP/eZS16C3zww9vxsIOS35yKvnKd MyoK7LGxOl7fvK3JDJpJCdaBPqlXpeviS6UkyK9/+Z3XtCKNBIV2pKubCYFkUnaXc8w1 Q9tijRKlWKR8uVIzUDXbUB20EmojTIf1VIP2BViRDEzEwXYVcGQF88zYFBzu14VgSsij /nug==
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=Xfl8M7vFIScIOdwvVhvTHTdsUpHmN+t2BLyg1IrXs2U=; b=fcGpob1pKHKgml5WkOVLiMleZE7vs/F90g0dTGOZ9mRdXAe/vvFt+O7SakiE9xT4nr HpbEvu/rfMBiWbYEMMyNvVYpjDPyakn7XC3Kjiz80BGqadMbULtySkyGDBlSuQL6orhd L1EWg1wdSjX6Bpgh1sx+Ovj8Wuny5xnZ6fq4FrnHLvO8hiflX7pZdq31MkeQuDC1JCt+ rx5l7y/p7jSXp1Ut6acAdSgJT4PZ7M8dyFxjdJdpLlQS+2l3dZ/MR/PvIbExlXojWLuq p8HmVvQR1JsgnUulw8LeH/lFuyy6+oF902NgctGgX/VcnO5M6zvrv2CWWuLnaJr8FitP PBPA==
X-Gm-Message-State: AE9vXwNmvw7JoW7CYbSneLbcjLhTZGh1hQ87k8JqJzMK6/PtsBTDd7KkyzvUOsESM/vjyYCLp73f2ikrI4oO+g==
X-Received: by with SMTP id c85mr26814540ywa.205.1474304077529; Mon, 19 Sep 2016 09:54:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Sep 2016 09:53:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 19 Sep 2016 09:53:57 -0700
Message-ID: <>
To: David Woodhouse <>
Content-Type: multipart/alternative; boundary=001a1142153cd57aff053cdf2a3f
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 16:54:40 -0000

On Mon, Sep 19, 2016 at 8:37 AM, David Woodhouse <>

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

This doesn't seem like the kind of behavior we want to encourage in

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

Well, I'm not saying you can't do that. As I said, you can use HRR if the

> because you've chosen to conflate PSK identities and session resumption
> on the wire? :)

As I said before, that's not the reason to restrict to a single identity.

> 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 :)

No, I don't think that's true. That extension also attempts to actually
negotiate the keys in that layer. I'm just talking about a hint.