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 >
- Re: [TLS] Pre_shared_key Extension Question David Benjamin
- Re: [TLS] Pre_shared_key Extension Question Eric Rescorla
- Re: [TLS] Pre_shared_key Extension Question Benjamin Kaduk
- Re: [TLS] Pre_shared_key Extension Question Eric Rescorla
- Re: [TLS] Pre_shared_key Extension Question Benjamin Kaduk
- Re: [TLS] Pre_shared_key Extension Question Eric Rescorla
- [TLS] Pre_shared_key Extension Question Hannes Tschofenig
- Re: [TLS] Pre_shared_key Extension Question Hannes Tschofenig
- Re: [TLS] Pre_shared_key Extension Question Hannes Tschofenig
- Re: [TLS] Pre_shared_key Extension Question Salz, Rich