"Perry E. Metzger" <pe...@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 majord...@metzdowd.com