Re: [TLS] Pre_shared_key Extension Question

David Benjamin <davidben@chromium.org> Thu, 18 August 2016 16:05 UTC

Return-Path: <davidben@google.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 8062312DF27 for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 09:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.946
X-Spam-Level:
X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 uo2ZBDC__mOr for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 09:05:52 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 5AE0C12D133 for <tls@ietf.org>; Thu, 18 Aug 2016 09:05:52 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id x131so2117513ite.0 for <tls@ietf.org>; Thu, 18 Aug 2016 09:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ve6TNclcLBNfias/RLz1vfGQe/nch00hh85jFFf6kIU=; b=ASguIwLWGYXtuVzj8KrpZvUOHXXBkEM/3gI3UT7Hk6DhogcC1eUwrjXpeEEOkW7/E7 xiNZTsM6Be73rOVEavRUF6Vww1llb7iVIRQncQZN1P043UO5jpjX/COTXnLe4VmziXB4 tiWdvdc+MJ49yEbzzggnLdGelBEa0zRmYzwjw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ve6TNclcLBNfias/RLz1vfGQe/nch00hh85jFFf6kIU=; b=RM6qhvmIGErgF53FyPG2BmV0WtH0rg9BAIvt7RBgraxtP4f87J05N3gFzVg/1fyL7R AGeRHeBhepyjATc7zF6EFkrwlgsHuLsKRVQHIUY6vIYMsov9MeBCzn1ZcFRHWgQxAA9o y/1ePUYq/sPBRUmxUmxJ/qOLpUi4C+5MV31hk+tA1SdCO5ltujvpPxxXrFAEO5pGSi7g pu7HT+XuKfNQCohzaL/M7dJCIDTTe7T7Iml6qtM53m/mjAmpcadlnzsrY5Kw0BfifzZZ ldfBB1/btrovPeB4ISFq/sjvKNVgYdG9nSTGgs4J2GR6Ipl/S+/9i8Oest9yBof6xaX8 cAzg==
X-Gm-Message-State: AEkoouvqgW1Iwn1Yi+xfrmJE4tXHlYhuPM9b6jfVsjSrSQZDVcvwgGvYOJDZeQuE6Dw1GilnGalJodFX3uWROIGh
X-Received: by 10.36.189.143 with SMTP id x137mr461022ite.18.1471536351321; Thu, 18 Aug 2016 09:05:51 -0700 (PDT)
MIME-Version: 1.0
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> <CABcZeBNgWi8CaFtvE2C5Z8mbQcGgYN-8g=oYw9Do6bVA5JsR7Q@mail.gmail.com>
In-Reply-To: <CABcZeBNgWi8CaFtvE2C5Z8mbQcGgYN-8g=oYw9Do6bVA5JsR7Q@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 18 Aug 2016 16:05:40 +0000
Message-ID: <CAF8qwaBVoDz_aP2Gt424BUriMU3Q_j2edJDbsEb8g5mVsGiB5A@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Benjamin Kaduk <bkaduk@akamai.com>
Content-Type: multipart/alternative; boundary=94eb2c19c0267efbd8053a5ac179
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B-_UxCbHAwkVCv96un9ZgPjG91c>
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 16:05:54 -0000

On Thu, Aug 18, 2016 at 11:54 AM Eric Rescorla <ekr@rtfm.com> wrote:

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

Note this would require that the client and server a priori agree they're
doing PSK-based identities and not certificate-based identities. Otherwise
the server doesn't know whether to do PSK + please use this identity
instead or full handshake + certs. Though that seems an okay requirement
since what kind of identities you use (PSK, X.509 web PKI, Kerberos,
whatever else) is more part of the application profile and not really
negotiated at TLS.

Another option for your scenario is you ensure that the 2016Q2 key is
installed on the servers before it is installed on any client. The server
is still allowed to accept multiple PSK identities whether there's one or
multiple client advertisements. The multiple client advertisement just
means you can install 2016Q2 in any order.

(I am not actually involved in PSK-based systems either. I too would love
to have only one PSK offer since, for resumption purposes, there's no need
for multiple. But I can't speak to actual PSK-based systems.)

David


> -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
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>