On Wed, Dec 16, 2015 at 2:57 PM, Brian Smith <br...@briansmith.org> wrote: > 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.
You need to actually read the papers and understand which formulas are modified. If you did you would see the improvement is in AES-GCM with funny nonce sizes, not the confidentiality issue. > > 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/ > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
