On 08/18/2016 10:29 AM, Eric Rescorla wrote: > > > On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <bka...@akamai.com > <mailto:bka...@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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
