Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

["Dang, Quynh (Fed)" <[e-mail]>]

Hi Kenny, 

On 7/12/16, 12:33 PM, "Paterson, Kenny" <[e-mail]> 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)" <[e-mail]>
>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:[e-mail]] On Behalf Of Dang, Quynh (Fed)
>>> Sent: Tuesday, July 12, 2016 11:12 AM
>>> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; [e-mail]
>>> 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" <[e-mail]>
>>> 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)"
>>> ><[e-mail] on behalf of [e-mail]> 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: "[e-mail]" <[e-mail]>
>>> >>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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>