ben at links.org
Thu Mar 25 09:24:16 EDT 2010
On 24/03/2010 08:28, Simon Josefsson wrote:
> "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:
>> 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
Note, however, that one of the reasons the TLS renegotiation attack was
so bad in combination with HTTP was that reauthentication did not result
in use of the new channel to re-send the command that had resulted in a
need for reauthentication. This command could have come from the
attacker, but the reauthentication would still be used to "authenticate" it.
In other words, designing composable secure protocols is hard. And TLS
isn't one. Or maybe it is, now that the channels before and after
rekeying are bound together (which would seem to invalidate your
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography