On Wed, Dec 16, 2015 at 6:17 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
> On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson <si...@josefsson.org>
> wrote:
>>
>> Eric Rescorla <e...@rtfm.com> writes:
>>
>> > Watson kindly prepared some text that described the limits on what's
>> > safe
>> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
>> > limit (2^{36} bytes), even though ChaCha doesn't have the same
>> > restriction.
>>
>> Can we see a brief writeup explaining the 2^36 number?
>
>
> I believe Watson provided one a while back at:
> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
>
>>
>> I don't like re-keying. It is usually a sign that your primitives are
>> too weak and you are attempting to hide that fact. To me, it is similar
>> to discard the first X byte of RC4 output.
>
>
> To be clear: I would prefer not to rekey either, but the consensus at IETF
> Yokohama
> was that we were close enough to the limit that we probably had to. Would be
> happy to learn that we didn't.
If you come up with a number for how many bytes we would send
maximally, I can see what the probability of a distinguisher would be.
There are a bunch of places I was sloppy. Personally I think 2^36
bytes over one connection is quite a lot, but it appears that people
are still worried about about this edge case.
Rekeying isn't that complicated conceptually, or from the standpoint
of how to integrate it in. Reauthentication is a lot worse.
>
> -Ekr
>
>
>
>> If AES-GCM cannot provide confidentiality beyond 64GB (which would
>> surprise me somewhat), I believe we ought to be careful about
>> recommending it.
>>
>> Of course, the devil is in the details: if the risk is that the secret
>> key is leaked, that's fatal; if the risk is that the attacker can tell
>> whether two particular plaintext 128 byte blocks are the same or not in
>> the entire file, that can be a risk we can live with (similar to the
>> discard X bytes of RC4 fix).
>>
>> I believe 64GB is within the range that people download in a web browser
>> these days. More data intensive longer-running protocols often transfer
>> significantly more.
>>
>> /Simon
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
--
"Man is born free, but everywhere he is in chains".
--Rousseau.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
