Re: [TLS] Pre_shared_key Extension Question

Benjamin Kaduk <> Thu, 18 August 2016 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD90912DE1C for <>; Thu, 18 Aug 2016 08:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.967
X-Spam-Status: No, score=-3.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vsK9v7Lez0lz for <>; Thu, 18 Aug 2016 08:47:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B185612DE9E for <>; Thu, 18 Aug 2016 08:47:09 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id CC2F0433424; Thu, 18 Aug 2016 15:47:08 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id B254F433408; Thu, 18 Aug 2016 15:47:08 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1471535228; bh=zRLpCZ9vVjH2PH/zS30BXPFocsFHBnhn6WNery1FkJY=; l=5552; h=To:References:Cc:From:Date:In-Reply-To:From; b=fsdQvpj24FSIPgvIcs7p+ASxL4nAImby8J2HCmNyyJiF9z39EwfRW6R+tNvJpeGIq mUmwq95baqSnxI/CNEwytG+DDzdv2mxhEYSjjxreCelOX/VeckbKzJnblRBpUwn/37 QowKxB5Qfv+6EI5MkI3en4Gsgj9oQ9sgg8/fXql8=
Received: from [] ( []) by (Postfix) with ESMTP id 7D6641FC88; Thu, 18 Aug 2016 15:47:08 +0000 (GMT)
To: Eric Rescorla <>
References: <> <> <> <>
From: Benjamin Kaduk <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 18 Aug 2016 10:47:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------EFC232BF323CBFD377C5DC31"
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:47:12 -0000

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.

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