Hi Benjamin,
regarding the use case you describe below: at least for us at ARM this
is not the way how we plan to use PSK. We use a key distribution
protocol (namely OMA LWM2M) to provision the PSK identity and the PSK
secret used with TLS.
So, from that point of view there is no need for a PSK rollover as you
describe below.
Ciao
Hannes
On 08/18/2016 05:47 PM, Benjamin Kaduk 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
<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
