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

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-bounces@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.Paterson@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-bounces@ietf.org on behalf of quynh.dang@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