Actually, a more correct way of viewing the limit would be 2^52 encrypted data bytes. To come to the 2^38 record limit, they assume that each record is the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take over a year to encrypt that much data...
> -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dang, Quynh (Fed) > Sent: Tuesday, July 12, 2016 11:12 AM > To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt > > Hi Kenny, > > The indistinguishability-based security notion in the paper is a stronger > security notion than the (old) traditional confidentiality notion. > > > (*) Indistinguishability notion (framework) guarantees no other attacks can > be better than the indistinguishability bound. Intuitively, you can¹t attack > if > you can¹t even tell two things are different or not. So, being able to say two > things are different or not is the minimal condition to lead to any attack. > > The traditional confidentiality definition is that knowing only the > ciphertexts, > the attacker can¹t know any content of the corresponding plaintexts with a > greater probability than some value and this value depends on the particular > cipher. Of course, the maximum amount of data must not be more than > some limit under a given key which also depends on the cipher. > > For example, with counter mode AES_128, Let¹s say encrypting 2^70 input > blocks with a single key. With the 2^70 ciphertext blocks alone (each block is > 128 bits), I don¹t think one can find out any content of any of the > plaintexts. > The chance for knowing any block of the plaintexts is > 1/(2^128) in this case. > > I support the strongest indistinguishability notion mentioned in (*) above, > but in my opinion we should provide good description to the users. > That is why I support the limit around 2^38 records. > > Regards, > Quynh. > > On 7/12/16, 10:03 AM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> > wrote: > > >Hi Quynh, > > > >This indistinguishability-based security notion is the confidentiality > >notion that is by now generally accepted in the crypto community. > >Meeting it is sufficient to guarantee security against many other forms > >of attack on confidentiality, which is one of the main reasons we use it. > > > >You say that an attack in the sense implied by breaking this notion > >does not break confidentiality. Can you explain what you mean by > >"confidentiality", in a precise way? I can then try to tell you whether > >this notion will imply yours. > > > >Regards > > > >Kenny > > > >On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)" > ><tls-boun...@ietf.org on behalf of quynh.d...@nist.gov> wrote: > > > >>Hi Eric and all, > >> > >> > >>In my opinion, we should give better information about data limit for > >>AES_GCM in TLS 1.3 instead of what is current in the draft 14. > >> > >> > >>In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what > >>is called confidentiality attack is the known plaintext > >>differentiality attack where the attacker has/chooses two plaintexts, > >>send them to the AES-encryption oracle. The oracle encrypts one of > >>them, then sends the ciphertext to the attacker. After seeing the > >>ciphertext, the attacker has some success probability of telling which > >>plaintext was encrypted and this success probability is in the column > >>called ³Attack Success Probability² in Table 1. This attack does not > >>break confidentiality. > >> > >> > >>If the attack above breaks one of security goal(s) of your individual > >>system, then making success probability of that attack at 2^(-32) max > >>is enough. In that case, the Max number of records is around 2^38. > >> > >> > >> > >> > >>Regards, > >>Quynh. > >> > >> > >> > >> > >> > >> > >>Date: Monday, July 11, 2016 at 3:08 PM > >>To: "tls@ietf.org" <tls@ietf.org> > >>Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt > >> > >> > >> > >>Folks, > >> > >> > >>I've just submitted draft-ietf-tls-tls13-14.txt and it should show up > >>on the draft repository shortly. In the meantime you can find the > >>editor's copy in the usual location at: > >> > >> > >> http://tlswg.github.io/tls13-spec/ > >> > >> > >>The major changes in this document are: > >> > >> > >>* A big restructure to make it read better. I moved the Overview > >> to the beginning and then put the document in a more logical > >> order starting with the handshake and then the record and > >> alerts. > >> > >> > >>* Totally rewrote the section which used to be called "Security > >> Analysis" and is now called "Overview of Security Properties". > >> This section is still kind of a hard hat area, so PRs welcome. > >> In particular, I know I need to beef up the citations for the > >> record layer section. > >> > >> > >>* Removed the 0-RTT EncryptedExtensions and moved ticket_age > >> into the ClientHello. This quasi-reverts a change in -13 that > >> made implementation of 0-RTT kind of a pain. > >> > >> > >>As usual, comments welcome. > >>-Ekr > >> > >> > >> > >> > >> > >> > >>* Allow cookies to be longer (*) > >> > >> > >>* Remove the "context" from EarlyDataIndication as it was undefined > >> and nobody used it (*) > >> > >> > >>* Remove 0-RTT EncryptedExtensions and replace the ticket_age > >>extension > >> with an obfuscated version. Also necessitates a change to > >> NewSessionTicket (*). > >> > >> > >>* Move the downgrade sentinel to the end of ServerHello.Random > >> to accomodate tlsdate (*). > >> > >> > >>* Define ecdsa_sha1 (*). > >> > >> > >>* Allow resumption even after fatal alerts. This matches current > >> practice. > >> > >> > >>* Remove non-closure warning alerts. Require treating unknown alerts > >>as > >> fatal. > >> > >> > >>* Make the rules for accepting 0-RTT less restrictive. > >> > >> > >>* Clarify 0-RTT backward-compatibility rules. > >> > >> > >>* Clarify how 0-RTT and PSK identities interact. > >> > >> > >>* Add a section describing the data limits for each cipher. > >> > >> > >>* Major editorial restructuring. > >> > >> > >>* Replace the Security Analysis section with a WIP draft. > >> > >> > >>(*) indicates changes to the wire protocol which may require > >>implementations > >> to update. > >> > >> > >> > >> > >> > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls