"Against Rekeying"

[Simon Josefsson]

"Perry E. Metzger" <perry at piermont.com> writes:

> Ekr has an interesting blog post up on the question of whether protocol
> support for periodic rekeying is a good or a bad thing:
>
> http://www.educatedguesswork.org/2010/03/against_rekeying.html
>
> I'd be interested in hearing what people think on the topic. I'm a bit
> skeptical of his position, partially because I think we have too little
> experience with real world attacks on cryptographic protocols, but I'm
> fairly open-minded at this point.

One situation where rekeying appears to me not only useful but actually
essential is when you re-authenticate in the secure channel.

TLS renegotiation is used for re-authentication, for example, when you
go from no user authentication to user authenticated, or go from user X
authenticated to user Y authenticated.  This is easy to do with TLS
renegotiation: just renegotiate with a different client certificate.

I would feel uncomfortable using the same encryption keys that were
negotiated by an anonymous user (or another user X) before me when I'm
authentication as user Y, and user Y is planning to send a considerably
amount of traffic that user Y wants to be protected.  Trusting the
encryption keys negotiated by user X doesn't seem prudent to me.
Essentially, I want encryption keys to always be bound to
authentication.

Yes, the re-authentication use-case could be implemented by tearing down
the secure channel and opening a new one, and that may be overall
simpler to implement and support.

However, IF we want to provide a secure channel for application
protocols that re-authenticate, I have a feeling that the secure channel
must support re-keying to yield good security properties.

/Simon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com