> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity. > > Any arbitrary limit for a TLS connection is almost guaranteed to cause > problems in the future. We cannot predict whether 2^x should be > sufficient for everyone, and I'm pretty sure this will prove to be a > terrible mistake. TLS is already being used for VPNs and transferring > larger amounts of data in long lived connections is a reality even > today. The rekey today happens using the reauthentication mechanism, > which has very complex semantics. Converting these to a simpler and > predictable rekey mechanism would be an improvement.
Agreed. The alternative to having a rekey mechanism is to push the complexity to the application protocol, requiring it to be able to use more than one connection to transfer all the data, which may require some sort of session layer to maintain state between connections. So unless we can guarantee or require that every algorithm we are going to use is good for some ridiculous amount of data (2^64 bytes may be enough), we need rekeying. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
