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