Re: [TLS] Data volume limits

[Watson Ladd <[e-mail]>]

On Wed, Dec 16, 2015 at 2:57 PM, Brian Smith <[e-mail]> wrote:
> Eric Rescorla <[e-mail]> 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.