Eric Rescorla <e...@rtfm.com> wrote: > > I believe Watson provided one a while back at: > https://www.ietf.org/mail-archive/web/tls/current/msg18240.html >
So, if [2] is correct, then we can take Watson's 2^36 and multiply it by 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that they've improved the bounds by 2^17. Note that 3 out of 4 of the authors of [2] are the same authors as [1], which is the paper that defined the formula that the 2^36 number was calculated from. Earlier (in another thread), we agreed that an implementation would not send 2^48 or more records. A limit of 2^53 bytes would allow for 2^39 maximally-sized (16KB) records, which is not far off from the 2^48 theoretical maximum that the record sequence number allows. More importantly, 2^53 == 10^15 == 1 petabyte == 1,000,000 gigabytes; I think we can live with an upper limit of byte sent that is even much smaller than that. [1] https://eprint.iacr.org/2012/438.pdf [2] https://eprint.iacr.org/2015/214.pdf Therefore, I think we shouldn't add the rekeying mechanism as it is unnecessary and it adds too much complexity. Also, the above limits apply to AES-GCM but not ChaCha20-Poly1305. So, at the very least, we should avoid the rekeying complexity for ChaCha20-Poly1305 and other AEADs that don't need it. And, implementations that don't intend to send these giant quantities of data, even with AES-GCM, shouldn't be required, implicitly or explicitly, to implement the rekeying. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
