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

Eric Rescorla <> Mon, 19 September 2016 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FC3312B3FE for <>; Mon, 19 Sep 2016 07:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 UOO2I8rZP10r for <>; Mon, 19 Sep 2016 07:56:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3933912B404 for <>; Mon, 19 Sep 2016 07:56:11 -0700 (PDT)
Received: by with SMTP id x93so88264613ybh.1 for <>; Mon, 19 Sep 2016 07:56:11 -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=tk8ikKlJj+HkYvyIkfFJ+HGL1Q/kywDVLxYrW+9+H5M=; b=hK0k4JJoumYsoQW0GtkAGFWPDifNQRzqQnNHFSN4w2bxTk5fWBU6X+AoOWJwG3tG18 By3khOjGOVO/FOqRQE4WoGX7jVGe0VWsihuHftCLuAqYVtUXj46aVtdTZKBdF73yj0nr p2/JGqpDJJtrB2FPvnqZPffOrAxU1uId6MHZiV9/O1r09bWDKbQcR0V6dAfX3Iwdz2KO h2DF3+zCCJxocnGUylkRR+eWtZ8fTiMJbmYQY0V8LWfn0RmwMAjypHESFpbcXjzNzrJI c5He9gjPyhDpaY1nGgMmC5dSyZ7Ko5BKSKxRCy8UlDUC7Do/nnrVJn9ME6GnHcgYAz7N xZIQ==
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=tk8ikKlJj+HkYvyIkfFJ+HGL1Q/kywDVLxYrW+9+H5M=; b=SVIQZ6tAIGJF+vHPOcXidn6a39aLt5J0P3wOBk+pqsSbEaU0SS1nylXWe4awYKcq7S ehnjfi9mDSTENKOfTiN/7HwgqHcDHLrkyO6Cs0i+OqXvUByr9UI3Sr30J8FflKzotRDy 4EuBMRA/UynAUyrYtS2zkS0k5rqCtDUGmWGQCTLHf612LYsO7FGrhUGIr6WcQgrTmOWr Mr+4II9VjINpliuAdkbsUDmAxsXi8vrHmutaWsg5GcZ7HBY5T8D5s4RkzxVaNA5kjTo7 FN+443GT5zHTK2MaTXpDRu6k1rxWcRuKd8ME4KJ7de1qhcEwXNrDjfwMDjgiH67auUyL C1FQ==
X-Gm-Message-State: AE9vXwMxZ5pCWVaevP1oFTfTQu9EeRSQInqFkvMSDBt6jCDo95+hIEUeEqQD4Ewt48Yb7eWKTlABg+3M7X1CnA==
X-Received: by with SMTP id g83mr26117610yba.64.1474296970230; Mon, 19 Sep 2016 07:56:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Sep 2016 07:55:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 19 Sep 2016 07:55:29 -0700
Message-ID: <>
To: David Woodhouse <>
Content-Type: multipart/alternative; boundary=001a114f5d9034b50e053cdd8379
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:56:21 -0000

On Mon, Sep 19, 2016 at 7:07 AM, David Woodhouse <>

> 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
> permitted?

I should start by saying that it's not entirely clear why this is useful.
Can you elaborate?

Or do we stop 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.

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

I can't speak for the motivations of the authors of this draft. It's not a
item. However, I'm not generally in favor of backporting pieces of TLS 1.3
into 1.2
like this.

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

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.
2. Wait for DTLS 1.3.


> --
> dwmw2