Re: [TLS] Pre_shared_key Extension Question

Eric Rescorla <ekr@rtfm.com> Thu, 18 August 2016 15:54 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98112DA2C for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 08:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ntcRIwBecSs for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 08:54:50 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF99F12DA24 for <tls@ietf.org>; Thu, 18 Aug 2016 08:54:49 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id j12so12195311ywb.2 for <tls@ietf.org>; Thu, 18 Aug 2016 08:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.13.244.197 with SMTP id d188mr2408908ywf.276.1471535689264; Thu, 18 Aug 2016 08:54:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.48.193 with HTTP; Thu, 18 Aug 2016 08:54:08 -0700 (PDT)
In-Reply-To: <b45384ae-bd1b-a079-2bb1-d56cd1b39644@akamai.com>
References: <fa85eafb-b2f5-b5c2-859a-a2e24d734324@gmx.net> <CABcZeBOBffGU6RWgfMkRhqzxLd-yUw0v_CoUvtdDyTR0Ubvm6A@mail.gmail.com> <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> <CABcZeBMM_OKPifQ=G+wEnUzJXfV=oJwoAa8zjLVTkHx94A798A@mail.gmail.com> <b45384ae-bd1b-a079-2bb1-d56cd1b39644@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 18 Aug 2016 08:54:08 -0700
Message-ID: <CABcZeBNgWi8CaFtvE2C5Z8mbQcGgYN-8g=oYw9Do6bVA5JsR7Q@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Content-Type: multipart/alternative; boundary=94eb2c08654808a01c053a5a9a6e
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q5Aokp8IdZfNem02IF9MZKdR6FM>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Pre_shared_key Extension Question
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 15:54:51 -0000

On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

> On 08/18/2016 10:29 AM, Eric Rescorla wrote:
>
>
>
> On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <bkaduk@akamai.com> 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.

-Ekr


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