Re: [TLS] Pre_shared_key Extension Question

Eric Rescorla <> Thu, 18 August 2016 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D98112DA2C for <>; Thu, 18 Aug 2016 08:54:51 -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 6ntcRIwBecSs for <>; Thu, 18 Aug 2016 08:54:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF99F12DA24 for <>; Thu, 18 Aug 2016 08:54:49 -0700 (PDT)
Received: by with SMTP id j12so12195311ywb.2 for <>; Thu, 18 Aug 2016 08:54:49 -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=mhGSs4wGTE6g1u91ft/SBp4/gZr/GHfLjgu5Vi2AyWg=; b=ciJnKRzn2gr05tN5TY4dpN3LYy0Be+uJ3K5B2YPIQE+AxufWFQWiyaKoDCvVRczAAj pG/71YS7SffFDySi61nXkbHWh7oz4H9Gvylz0+UmIkfsWcAuz2EVfOr6hQTJlCE1iFl8 i0VILJ2MEHIEzE9cnEPt+5rJTqpw569IDHdkcsa3okXipIDYTemcgDHdML1dqXtNqi6Y SkmwWf95NPD0BOff77SSQq52vs9jbjebs1FRH7KvARkJ0sdJWkilHgsgo8sBZWgtfSGj cWfcpj2Ls9veJCTbSv0EUt94Kx4J7mTtmHsExe1cyBwZyQbqhUURMwkIwo8rOiTS9rpu jZtA==
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=mhGSs4wGTE6g1u91ft/SBp4/gZr/GHfLjgu5Vi2AyWg=; b=JdkSkHc9tkHiIInImkGJBKaLBKLQugRtus0TBrLWM3hlsFsS5m9zZ0E5mzTTPuuLGB LiM00sWExfpl97aAExHelEwNe40EOQtlxt/3Hs2hO6Q4ygpbXJvfnOOPfDaQX9OfaQMv ECfwzNccSB0sZJUcXjUBsp/N0+vYhVjMbI+EIsihqOO6i5BPI4XTJCXEdTRlkqJGc+tq s1yPP3S5yJp+F3SCwvhIb2zW6yLiBKwQ+c5OJnGNh1J9Cck1LjB4+khNge2gduL9geM4 uI9ENOLx+LEr0SZxaHSe4RrAxvxI2yF3ZaOoK7BzWTC/0WF7ioaMvkCZ2QxvbuqnqutE QY4Q==
X-Gm-Message-State: AEkoouu+ycgg3YjmbnihEKysUn+UwnDOCHbmA7ipSF2KpbMNIm3qL5wx+/HSMTy0RvEEyNkvv0/TB2orzJJU3A==
X-Received: by with SMTP id d188mr2408908ywf.276.1471535689264; Thu, 18 Aug 2016 08:54:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Aug 2016 08:54:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 18 Aug 2016 08:54:08 -0700
Message-ID: <>
To: Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary=94eb2c08654808a01c053a5a9a6e
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Pre_shared_key Extension Question
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: Thu, 18 Aug 2016 15:54:51 -0000

On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk <> wrote:

> On 08/18/2016 10:29 AM, Eric Rescorla wrote:
> On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <> wrote:
>> On 08/17/2016 05:17 PM, Eric Rescorla wrote:
>> It would be a fairly significant simplification to say you could only
>> have one PSK, because then we could easily require the client to prove
>> knowledge of the key, for instance by stuffing a MAC at the end of the
>> ClientHello as we discussed in Berlin.
>> So:
>> Is there any demand for multiple identities? I do not believe there is
>> any in the Web context. If not, we should remove this feature.
>> Then at PSK rollover time, clients are expected to fall back to a new TLS
>> connection using the other PSK?
> I'm not sure I follow. Can you say more?
> With caveat that I don't deploy PSK-based systems and this is before my
> morning coffee ... suppose I have a related group of IoT devices that use
> TLS+PSK to communicate.  But, I don't want the long-term cryptographic
> secret (the PSK) to be permanent and unchanging, since that's not best
> practices and leaves me in a tough spot if it ever leaks.  So, I generate a
> new PSK every three months, provide a device on the network that lets the
> devices retrieve the new one, and everyone is supposed to expire the old
> one a month after the new one is available.  My PSK identities could then
> be something like "2016Q2" (or something more complicated; it doesn't
> really matter), but since the devices are autonomous and not synchronized,
> I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 key.
> At some point, a device will try to use the 2016Q2 key as a client against
> a server device that only has the 2016Q1 key, and the handshake fails.  In
> the rollover scenario I describe, the client can then try a new handshake
> with the 2016Q1 key instead of the 2016Q2 key, which should succeed.

That would be the implication at this point, I think, though one could
imagine having some HRR version that was like "I have no idea about this
PSK". This would be easy with davidben's proposed new HRR Structure.


> Given the benefits of only allowing one PSK identity from the client, I am
> fine with requiring the second hanshake in this (contrived?) scenario; I
> just wanted to mention it so that we know what we're getting into.
> -Ben