Re: [TLS] Pre_shared_key Extension Question

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 09 September 2016 14:47 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 E4A3912B039 for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Level:
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 u_-_UmcZovnw for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:47:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489A512B166 for <tls@ietf.org>; Fri, 9 Sep 2016 07:47:41 -0700 (PDT)
Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MTMzb-1baMd702xL-00SPc8; Fri, 09 Sep 2016 16:47:34 +0200
To: Benjamin Kaduk <bkaduk@akamai.com>, Eric Rescorla <ekr@rtfm.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: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Message-ID: <daf435c4-ea38-2abc-a68a-d81c0bb8d844@gmx.net>
Date: Fri, 9 Sep 2016 16:47:31 +0200
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: <b45384ae-bd1b-a079-2bb1-d56cd1b39644@akamai.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:WX0FOSOors4ozT/9hERammLJAdyEHBh101Uh7Jk3K5qvjJj4a0c VCOmYGDdlfl+nL0AI130ocfdKexBRj+rpRP7qYvidyTEogTw1aqNoHAsWSRNQZVXahcrtAz n4EAjGs3giVk49LwEe7ii0DulJLgePSVxS2oJNCPki2pVusItgReqTeJc3laSeuhIaSLwjr N/PCs1yEafdTpnyeMMyCQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:C/yEAo0wNFA=:KTyHVvAl11N3KAgQ6ktcM4 1OTXFYcroqgtvEWN+rzz2kX3UIj8JbDwFnlck6XW8UuSkRLdgoEkjjAxl7mhpADqZvb7sEUh0 TISMnOjRgzMh2cAZEbngtd3t7UqFniwDUv17u0ZQwOnykimbpvoUJiag2TnzNVyg5NrFj8kg1 b4xU7/pMRGCoqsahfFb5w2X8NWjvQWi1oQTd9qhh8GIkDsBtaMSYDKImB/tUYY7WmmZQR/amP 931i51HebNcZ6A2ixPRLob1kjCMd1tRqOSaBjGoPHxKx64WHhSUrxUHFoZsOIzkryX/v2dgaM enBJC5VJUVGdBLs1w7BnPzJf96BKhdZUiGnWOTPm4pycYmHm+fG6yq3cmXDr2pa1KNccQt9ir C/+yQvVsU2AAe/B5rq3S+3/WqH+kd/EE7SsOCc8Kqu4WPq7xvmcbBMQtV3OvefY2hQevMqNpI fu3PyvuEclzpQbt0PZh8q/xcFUt2yonZhz0EPV2CNtPD9HCRU65BmxOEKj5TX5cfYPASjSPin 7OvR8ytTeL50klH19S4PNVQHLAbcBzGTRsNhWc13WoP4P//BEd57HEGprE+BJK4I8LeUNB8xX 3rVXnP007Ab9PRzf/y/QLQwb6cFp76JDIq/M4Ld+8U4bwm2bG2Efc7ClgkDOEDcWnOpnNp5vN GF8/kiL02rf0Gh2sGW9Y6+SOVPWq3t9wRLxOtNO8FOCKb6COlVdAJa46CfZV92TcFWYNSXtzI Oe+1s+xCyGVDOJ5Nb8hceZwpJK+Clwn75kwwyw2QeVBE8PbhK0yEaFzlVU250xQgh8RYCH5HZ cqllMvS
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TveHFxptakuKmyDqY9SxRmYd5rM>
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: Fri, 09 Sep 2016 14:47:47 -0000

Hi Benjamin,

regarding the use case you describe below: at least for us at ARM this 
is not the way how we plan to use PSK. We use a key distribution 
protocol (namely OMA LWM2M) to provision the PSK identity and the PSK 
secret used with TLS.

So, from that point of view there is no need for a PSK rollover as you 
describe below.

Ciao
Hannes

On 08/18/2016 05:47 PM, Benjamin Kaduk 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
>> <mailto: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.
>
> 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