[145179] in cryptography@c2.net mail archive
Re: "Against Rekeying"
daemon@ATHENA.MIT.EDU (Simon Josefsson)
Thu Mar 25 08:42:40 2010
From: Simon Josefsson <simon@josefsson.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: cryptography@metzdowd.com
Date: Wed, 24 Mar 2010 09:28:08 +0100
In-Reply-To: <87sk7rnjxe.fsf@snark.cb.piermont.com> (Perry E. Metzger's
message of "Tue, 23 Mar 2010 11:21:01 -0400")
"Perry E. Metzger" <perry@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@metzdowd.com
