Re: [TLS] Pre_shared_key Extension Question

[Eric Rescorla <[e-mail]>]

On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk <[e-mail]> wrote:

> On 08/18/2016 10:29 AM, Eric Rescorla wrote:
>
>
>
> On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <[e-mail]> 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
>