Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Fri, 10 February 2017 19:36 UTC

Return-Path: <quynh.dang@nist.gov>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C090129B25 for <cfrg@ietfa.amsl.com>; Fri, 10 Feb 2017 11:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 F_7xSwNfeU2p for <cfrg@ietfa.amsl.com>; Fri, 10 Feb 2017 11:36:29 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0135.outbound.protection.outlook.com [23.103.200.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AA3129B24 for <cfrg@irtf.org>; Fri, 10 Feb 2017 11:36:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/RC4K1ufqEUjFKfO3hV6JxqyREy5B+X+4Ap5X2ylSOE=; b=tb0AR19uLfrFkx+ChxBNK7ffOPlFEiPO9rRKvw1oLlzShMWaS0lmf2f05XngUCQ8K5zG9+ucIKVzFJcN96/jWTDmCuquLMylpjGnjPy16CmrU/MSZzYb3CnoRIl47GptwKwqgTBhtaN1qjsbxe1tYr015a66kGBi0KyUsQPdDeQ=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 19:36:27 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 19:36:27 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Rene Struik <rstruik.ext@gmail.com>, Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg84y+88vw5exDE6fOqGEW6ep0KFimMQAgAAIvxk=
Date: Fri, 10 Feb 2017 19:36:27 +0000
Message-ID: <CY4PR09MB146415E668A3DA0484190BC9F3440@CY4PR09MB1464.namprd09.prod.outlook.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <eeef0b36-2fdd-8de0-3bd7-7f0c5b68e9e9@gmail.com> <D4C3749F.2F856%qdang@nist.gov>, <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com>
In-Reply-To: <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.105.150]
x-ms-office365-filtering-correlation-id: af8743ad-29f3-4eb2-9bad-08d451ec1b1a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:Tvmz1I9smEOm634E2dtS/81MKf6JD46qJvRc18qtWl4vLJGdx5K2mrUpOLTzRH+s8Y9AQZrBdRmovUFkIm7RBv/VybzvDclEDzGQC1FgRmUlSKw47BH89xakgL95d4hwrXHtV3aMDQOV0JCfLjA6nh55TgyHq/fcLHVjtoJ7KiPzTFSH0wxZR4c9VMPJYNQ41XAVILS/SjlqvyawGzCrJsGvlWoKJ40ybni1Io5ehLnCTLVfLAz1bVzMZFzMpvehOvX/WusZuzTU9ILUymhU+fMtXDTjHB2zK5j+GctlBPieX7/Kel+44hON2aC6SOzf5PDZ1NQS83jnUbWXyfo0SjlOZdYVJi/8H/MKmXVXIFiiDLRAj+7ExeAPCycWlHyFAF8j+t+akG0qfBcL609eEs+yM/7+HtK7QPJne7iqcSf81akTh8oZURrODJHjcpS9garZ6BvY4bHXrFsX4/ysdCL7YnQgc3uPDmmenVBGvHvxjfGNdJ1DOheBvj6nV3fpUeV+RX3N4yXhCRtjnIw4Gw==
x-microsoft-antispam-prvs: <CY4PR09MB1461BDC17D34D8CDD415F314F3440@CY4PR09MB1461.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(166708455590820)(100405760836317)(131022147185803);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(199003)(24454002)(377454003)(189002)(86362001)(122556002)(575784001)(50986999)(66066001)(54356999)(3280700002)(76176999)(189998001)(3660700001)(4326007)(68736007)(2906002)(2900100001)(81166006)(81156014)(38730400002)(7906003)(8936002)(16297215004)(39060400001)(74316002)(8676002)(7736002)(106356001)(105586002)(6246003)(53546003)(106116001)(19627405001)(3846002)(7696004)(92566002)(77096006)(229853002)(6436002)(2950100002)(966004)(5660300001)(9686003)(99286003)(102836003)(93886004)(55016002)(325944008)(33656002)(97736004)(101416001)(236005)(606005)(54896002)(25786008)(6116002)(6506006)(6306002)(53936002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 19:36:27.3491 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6uUQu35tauBKGFe17mJebW60X0E>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2017 19:36:33 -0000

Hi Rene,


I care about side channel attacks in general as much as you do. But my question was that how you carry out those attacks on GCM in TLS 1.3's servers and clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 ?


Quynh.

________________________________
From: Rene Struik <rstruik.ext@gmail.com>
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner; <tls@ietf.org>
Cc: IRTF CFRG
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Quynh:

Not sure where to start (there is vast literature on side channel attacks and other implementation attacks). A good starting point would be the book [1], but one could also look at some NIST publications [2].

Side channel attacks differs from cryptanalytic attacks in that it does not merely study I/O behavior of crypto contructs, but also looks into what information can be obtained from what is going on "under the hood" of the computations (power consumption, radiation, timing, etc; or even invasive attacks). Most commonly one looks at crypto building blocks, but ultimately side channels can comprise any system behavior ("Lucky13" does, e.g., exploit this, if I remember correctly).

>From the last page of [2]: Finally, the most important conclusion from this paper is that it is not only a necessity but also a must, in the coming version of FIPS 140-3 standard, to evaluate cryptographic modules for their resistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
Hi Rene,

From: TLS <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>> on behalf of Rene Struik <rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>>, "<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Cc: IRTF CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]


There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS]<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS> provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update Section 4.6.3<https://tlswg.github.io/tls13-spec/#key-update> prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel attacks, which - in some implementations - have been shown to be successful at recovering keying material with a relatively small number of messages encrypted using the same key. While results are highly implementation-specific, thereby making it hard to provide precise guidance, prudence suggests that implementations should not reuse keys ad infinitum. Implementations SHALL therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks work for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:

All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>https://www.irtf.org/mailman/listinfo/cfrg



--
email: rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



--
email: rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363