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

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

Hi Kenny, 

On 7/12/16, 1:05 PM, "Paterson, Kenny" <[e-mail]> wrote:

>Hi
>
>On 12/07/2016 16:12, "Dang, Quynh (Fed)" <[e-mail]> wrote:
>
>>Hi Kenny,
>>
>>The indistinguishability-based security notion in the paper is a stronger
>>security notion than the (old) traditional confidentiality notion.
>
>Well, indeed, I'm somewhat aware of the notion and its emergence over the
>years. Indeed, I have had the very real pleasure of writing a few research
>papers using indistinguishability-based security notions! Resisting the
>temptation to give you chapter and verse on your analysis of the notions
>and how to interpret them...
>
>>
>>(*) 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.
>
>OK, I think now we are at the heart of your argument. You support our
>choice of security definition and method of analysis after all.
>
>And we can agree that good descriptions can only help.
>
>>That is why I support the limit around 2^38 records.
>
>I don't see how changing 2^24.5 (which is in the current draft) to 2^38
>provides a better description to users.
>
>Are you worried they won't know what a decimal in the exponent means?
>
>Or, more seriously, are you saying that 2^{-32} for single key attacks is
>a big enough security margin? If so, can you say what that's based on?

It would not make sense to ask people to rekey unnecessarily. 1 in 2^32 is
1 in 4,294,967,296 for the indistinguishability attack.

>Cheers,
>
>Kenny

Regards,
Quynh. 

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