Martin Thomson <martin.thom...@gmail.com> wrote: > Whatever the actual limits are, I think that implementatios should be > encouraged to rekey more strongly. >
Why? > And suggesting a stupidly high limit (e.g., ChaCha being > greater than 2^96) leaves people thinking that they can skip > implementation and testing of the rekey facility; or it just goes > unused. If it's not in use, then we'll have a good chance of creating > a protocol feature we can't rely on if it really is needed. > I think this is exactly why the limit matters. If we are not in danger of reaching the limit, then we don't need the rekeying mechanism and it should be removed. The rekeying mechanism adds considerable complexity and that complexity needs to be justified. Alternatively, we'd need a new justification for the rekeying mechanism. The new justification would affect the design of the rekeying mechanism. For example, if the purpose of the rekeying mechanism is to get similar effects to, say, the Axolotl ratchet, then we should ensure that the rekeying mechanism actually has similar properties to Axolotl. In light of that, the actual limits don't matter that much to me. As > David McGrew suggested, set a limit at 2^32 and avoid having to think > too hard about how close to the failure point you might be. First, let's figure out why TLS 1.3 needs a rekeying mechanism, if it does. Then we can figure out how frequently we should suggest rekeying occur based on sound reasoning. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
