Re: [TLS] Data Volume Limits Analysis

aluykx <Atul.Luykx@esat.kuleuven.be> Wed, 23 March 2016 08:11 UTC

Return-Path: <atul.luykx@esat.kuleuven.be>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90312D62D for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 01:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXPLna8FzQ-5 for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 01:11:56 -0700 (PDT)
Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA7412D1AD for <tls@ietf.org>; Wed, 23 Mar 2016 01:11:55 -0700 (PDT)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 959D6128163.A24A4
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 959D6128163; Wed, 23 Mar 2016 09:11:52 +0100 (CET)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id 923052009A; Wed, 23 Mar 2016 09:11:43 +0100 (CET)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 8FE1D60030; Wed, 23 Mar 2016 09:11:43 +0100 (CET)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 891BB40; Wed, 23 Mar 2016 09:11:43 +0100 (CET)
Received: from eduroam-24-4.eduroam.ruhr-uni-bochum.de ([134.147.24.4]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Wed, 23 Mar 2016 09:11:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 23 Mar 2016 09:11:43 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: aluykx <Atul.Luykx@esat.kuleuven.be>
To: Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <CABcZeBPhtdjvduRBK2ibFCiapuEJsQjtJwsWg_Ac8swyONUGVg@mail.gmail.com>
References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> <CABcZeBPhtdjvduRBK2ibFCiapuEJsQjtJwsWg_Ac8swyONUGVg@mail.gmail.com>
Message-ID: <0b6588fb0237c89d71192560b3487e11@esat.kuleuven.be>
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99 at cobalt
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Rlhyg5kK3TQpKEnlNEEUKyM5j6c>
Cc: tls@ietf.org
Subject: Re: [TLS] Data Volume Limits Analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2016 08:12:00 -0000

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 <Atul.Luykx@esat.kuleuven.be>
> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls