On Thu, Aug 18, 2016 at 11:54 AM Eric Rescorla <e...@rtfm.com> wrote:
> 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. > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
