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

["Paterson, Kenny" <[e-mail]>]

Hi

> On 12 Jul 2016, at 18:57, Dang, Quynh (Fed) <[e-mail]> wrote:
> 
> 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.
> 
> My understanding is that the total is the data complexity limit (counting
> block encryptions and queries which are also block encryptions).

Yes. And you can approximately convert between them by dividing by the block size (128 bits for AES). 

> To be
> more precise, then we should count data complexity by number of block
> encryptions (encrypting 1 bit is 1 block encryption). But for large data
> in TLS, encryption is pretty much with full blocks of plaintexts.

Yes. For our analysis, we assume 2^14 bytes per record. This equates to a whole number of AES blocks. You can add one more block per record if you want to, to cater for any rounding up, but it makes only a tiny difference to the final bounds. 

> If the attacker has 2^10 encrypted blocks and  is allowed to query another
> 2^10 encryptions, then the total data is 2^20 because the total of 2^20
> block encryptions happens. In TLS, it means that 2^20 AES block
> encryptions happen.
> 
I'm not sure I understand this. It's perhaps worth rereading what I wrote just below about why we assume 2^14 bytes per record. 

Cheers,

Kenny

>> 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.
>> 
>> 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
>