On 01/04/2016 06:22 AM, Florian Weimer wrote: > On 01/04/2016 01:19 PM, Hubert Kario wrote: > >>> Dealing with this during the initial handshake is fine. But >>> supporting direction-switching after that is *really* difficult. >> yes, this is a bit more problematic, especially for one-sided transfers. >> For example, when one side is just sending a multi-gigabyte transfer as >> a reply to a single command - there may be megabytes transferred before >> the other side reads our request for rekey and then our "CCS" message > Yes, this is the issue I meant. I simply don't see a way to re-inject > new randomness without a round-trip. (Key update without new randomness > doesn't face this challenge, but then it's mostly cheating.) >
EKR asked for an explanation of what risk you want to mitigate by adding new randomness on the 28th of December, but I don't recall seeing an explanation. This belief that key update without new randomness is undesirable does not really seem to be supported by any concrete arguments, in the recent history of this thread. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
