Hi Kenny, On 7/12/16, 12:33 PM, "Paterson, Kenny" <kenny.pater...@rhul.ac.uk> wrote:
>Unfortunately, that's not quite the right interpretation. The bounds one >obtains depend on both the total amount of data encrypted AND the number >of encryption queries the adversary is allowed to make to AES-GCM under >the (single) target key. > >We assumed each record was 2^14 bytes in size to simplify the ensuing >analysis, and to enable us to focus on how the security bounds then depend >on the number of records encrypted. See equation (5) and Table 2 in the >note at > > http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf. > >In short, the security bound does not necessarily hold for ANY 2^52 >encrypted data bytes. For example, if the attacker encrypted 2^52 records >of size 1 (!) then equation (5) would tell us almost nothing useful at all >about security. > >Finally, you write "to come to the 2^38 record limit, they assume that >each record is the maximum 2^14 bytes". For clarity, we did not recommend >a limit of 2^38 records. That's Quynh's preferred number, and is >unsupported by our analysis. What is problem with my suggestion even with the record size being the maximum value? > >Cheers, > >Kenny Regards, Quynh. > > > >On 12/07/2016 16:45, "Scott Fluhrer (sfluhrer)" <sfluh...@cisco.com> >wrote: > >>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
