Re: [TLS] Data Volume Limits Analysis

[aluykx <[e-mail]>]

Hey,

> 1. As I understand it, failure in these models is fairly catastrophic,
> so I should be reading Table 1 as "chance of total collapse of
> confidentiality",
> not "chance of being able to read one plaintext" value. Is that 
> correct?

Actually, confidentiality will not collapse, the limit indicates the 
moment when information starts leaking, which could start off as little 
as one bit of plaintext. The bigger issue is when integrity fails. For 
AES-GCM this could lead to the integrity key being recovered, allowing 
adversaries to forge TLS records (though to do so for chosen plaintext 
messages needs a bit more adversarial capability - essentially, enough 
contiguous known plaintext at the start of a record for some TLS 
sequence number).


> 2. Are there available proofs for a non-chosen plaintext context? This
> seems
> to bear on the multiple key question: it seems plausible that an
> attacker could
> capture a very large number of AES-GCM encrypted connections passively,
> but collecting a huge number of AES-GCM connections where it gets to
> specify the plaintexts seems more challenging, even with BEAST-style
> attacks.

As far as we know, there are no non-chosen plaintext proofs, however, 
the bounds do not improve when only considering known-plaintext attacks. 
Also, analysis where the adversary only sees ciphertext is not very 
realistic since in practice one can always deduce something about the 
plaintext.


> 3. Naively, from equation 5, it seems like as \sigma >> q you should be
> able
> to encrypt rather more submaximal (e.g., 1K) records than maximal size
> records.

If \sigma >> q, this means you've processed many long records. Switching 
to short records will allow you to process more of them, although the 
amount of data you can process will not change.

> Finally, and this calls for an opinion: do you believe that given these
> results
> we should include a KeyUpdate feature in TLS 1.3?

Ideally it would be better to include a KeyUpdate feature, but the added 
complexity could risk introducing vulnerabilities worse than what 
happens when the bounds are not respected, since all of these attacks 
require adversaries to monitor large amounts of data. If KeyUpdate is 
simple, then include it, but otherwise it might not be worth the risk.

Kenny and Atul


On 2016-03-21 00:40, Eric Rescorla wrote:
> Atul, Kenny,
> 
> Thanks for doing this. My initial impression is that these results are
> uncomfortably
> close to the line for AES-GCM, especially for the scenario where we
> have multiple
> keys: there are probably well upward of 2^{32} HTTPS connections a
> day.
> 
>  A few questions:
> 
> 1. As I understand it, failure in these models is fairly catastrophic,
> so I should be reading Table 1 as "chance of total collapse of
> confidentiality",
> not "chance of being able to read one plaintext" value. Is that
> correct?
> 
> 2. Are there available proofs for a non-chosen plaintext context? This
> seems
> to bear on the multiple key question: it seems plausible that an
> attacker could
> capture a very large number of AES-GCM encrypted connections
> passively,
> but collecting a huge number of AES-GCM connections where it gets to
> specify the plaintexts seems more challenging, even with BEAST-style
> attacks.
> 
> 3. Naively, from equation 5, it seems like as \sigma >> q you should
> be able
> to encrypt rather more submaximal (e.g., 1K) records than maximal size
> records.
> 
> Finally, and this calls for an opinion: do you believe that given
> these results
> we should include a KeyUpdate feature in TLS 1.3?
> 
> Thanks,
> -Ekr
> 
> On Tue, Mar 8, 2016 at 2:16 PM, aluykx <[e-mail]>
> wrote:
> 
>> Kenny Paterson and I prepared a document providing an overview of
>> how much data ChaCha20+Poly1305 and AES-GCM can process with a
>> single key. Besides summarizing the results, the document also gives
>> an explanation of why the limits are there. The document confirms
>> the analysis done by Watson and others in the thread on "Data Volume
>> Limits", but goes into more detail.
>> 
>> The document can be found on Kenny's website:
>> http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf
>> 
>> Atul Luykx
>> 
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls