Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 12 July 2016 15:48 UTC
Return-Path: <sfluhrer@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E812D7FC for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 08:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level:
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gWxAMLNMFht for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 08:48:13 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C150012D1DC for <tls@ietf.org>; Tue, 12 Jul 2016 08:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6738; q=dns/txt; s=iport; t=1468338333; x=1469547933; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CQfMJIxJMImv3DQhjBnlC7eWotzbNPBHLOfuc3RqutY=; b=NO2wrU89zfD0Qb3QMcJZdQIvmEX0iSj8RdtnUDruJnLX+nVeGYuMx6Zp Hd/KfYIySUETmZ4Kjopa+A+MTdws9X8kDbUj0yvWs1Qenc6+HJ+P9hxOS nqlzK43xXjE2YvlYW0gS+jckLHYIP4kegJnSUpq2VxDqj7vmGDNk+md91 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A/AgCcD4VX/49dJa1cDgiDKFZ8BrkDgXkihXYCgTU4FAEBAQEBAQFlJ4RcAQEDAgEBbBcEAgEIEQMBAQEBJwcnCxQJCAIEARIIDIgcDsAQAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2EHhMXMYUjBYgfhiCKXAGGDoJ6hUSBcU6HOYU9hluJOAEeNoIGH4ERO24BAYdgRH8BAQE
X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="296202809"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2016 15:45:32 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6CFjW9f016292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 15:45:32 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 11:45:30 -0400
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 11:45:30 -0400
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26epuiTmg3+eU0yJfAjoGH7+FKAVB4KAgAAQs4CAABMcgP//w17w
Date: Tue, 12 Jul 2016 15:45:30 +0000
Message-ID: <d1f35d74e93b4067bf17f587b904ebff@XCH-RTP-006.cisco.com>
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <D3AA5BD6.27AC0%qdang@nist.gov> <D3AAB674.709EA%kenny.paterson@rhul.ac.uk> <D3AA7549.27B09%qdang@nist.gov>
In-Reply-To: <D3AA7549.27B09%qdang@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Eip2rhyfnLKrsUgNhmjBxYQdjK8>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 15:48:15 -0000
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
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Peter Gutmann
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Watson Ladd
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Hubert Kario
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dave Garrett
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny