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

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Wed, 15 February 2017 12:11 UTC

Return-Path: <quynh.dang@nist.gov>
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 965AC129567 for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 04:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, URIBL_BLOCKED=0.001] autolearn=ham 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 CNC3zaUkIbMT for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 04:11:54 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0114.outbound.protection.outlook.com [23.103.201.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEC0129495 for <tls@ietf.org>; Wed, 15 Feb 2017 04:11:54 -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=D7veV6v2X2BlPwUiF362sH96WxmtHtgP7BmaOQF5x2Q=; b=MAV86Yvb00JvCPifQJMFThANJpz2fYenPu9ThyC9dn840Bm3gc5/elvSU3a74aZMIdP87Pc3jywhff3DAG/8zkrSrGIQr/bobocf/kQh8F7i1ToZBRJwvPyaTYA7fewYxHVFPgMhP2fr3IUf0eYdw1RC4UFoyZ/9F7X/Qetkxuk=
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; Wed, 15 Feb 2017 12:11:51 +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.030; Wed, 15 Feb 2017 12:11:51 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Atul Luykx <Atul.Luykx@esat.kuleuven.be>, Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwyaNRpm4jTNwkW4fHeK7pLqGKFpp3IA
Date: Wed, 15 Feb 2017 12:11:50 +0000
Message-ID: <D4C9AB9C.302D5%qdang@nist.gov>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <CABkgnnVrFGHe0eKREXbG_pv=y18ouopZsE2c5+Czz0HAGko6rg@mail.gmail.com> <D4C331C7.86224%kenny.paterson@rhul.ac.uk> <VI1PR8303MB0094D686941D99290BB431FCAB590@VI1PR8303MB0094.EURPRD83.prod.outlook.com> <D4C73D19.2FB4B%qdang@nist.gov> <D4C85054.2FDA4%qdang@nist.gov> <be49d59e37339cbaea8fef9bdb2a8971@esat.kuleuven.be> <D4C8AE28.30145%qdang@nist.gov> <CY4PR09MB1464278F1845979862CA9C8EF3580@CY4PR09MB1464.namprd09.prod.outlook.com> <BD6FC1F4-F2ED-46F8-9E53-862B69D9C00A@gmail.com> <e7c9bc1fb1b57333bacbe2def2687d18@esat.kuleuven.be>
In-Reply-To: <e7c9bc1fb1b57333bacbe2def2687d18@esat.kuleuven.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:3ioq2qNaXfhh2ZevHNxSFqw9v9soSxAmz8pjc9gy3+GlJVyUT+yfQfwpZ+hlq619joha/ZUxajhjRRC/b1Lr39KD7j7wUjW/LMlIVaLRgRSp/9HC7RdZgl5ZUYuFWJm0fN31mVrg297GfIuc3+K3jNzmUmanmeSpNpwdW9FxUWT3rYqd8QoajH+ORTbn+50UUXmZm70yRY+IobR7szBSQ53XutO+gSyRCzvQGQogiMzWr7F2cqDRGVzDX99gWDlKxf3Jk97ZDE5hv9ZyTCzf/CAb9f8JTe/wgqHcB00IdGZxk1fZPhQjQpDy2Ylt6m+U70oT3ivKUWFrMG6c1PNXFwgF23cDrXH/w49QMrnNtvOJhytMHVJKdTD6hK3oUWD3h+PKxcafroI06d0rvwapK2lrCs1FyTNOXDqvB670lr/aU4Hj37uewfifuyPiBJhwi87Ys1mLGp9bnf22jdcoRsFwzYGEYu6Ov1lYh5wiR724jsovabZRVx7huhm9DoEIlOl5rsSmzBc1mGHPxYsWIw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(199003)(189002)(377424004)(229853002)(99286003)(54906002)(50986999)(76176999)(101416001)(93886004)(102836003)(54356999)(36756003)(53936002)(3846002)(389900002)(2906002)(6116002)(86362001)(3280700002)(106116001)(81156014)(81166006)(92566002)(8676002)(106356001)(6246003)(606005)(54896002)(6512007)(6306002)(3660700001)(122556002)(105586002)(189998001)(236005)(4001350100001)(66066001)(25786008)(8936002)(4326007)(6436002)(77096006)(83506001)(2950100002)(68736007)(6506006)(7736002)(5660300001)(6486002)(53546003)(2900100001)(39060400002)(97736004)(38730400002)(7906003); 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;
x-ms-office365-filtering-correlation-id: 8c7ee9a8-5fff-4500-262d-08d4559bd2c4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461;
x-microsoft-antispam-prvs: <CY4PR09MB146140E2EB3F44A797378E1FF35B0@CY4PR09MB1461.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461;
x-forefront-prvs: 021975AE46
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_D4C9AB9C302D5qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 12:11:50.8492 (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/tls/CR0GS_xQEECPV7l22LgnEquc3qQ>
Cc: IRTF CFRG <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
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: Wed, 15 Feb 2017 12:11:56 -0000

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx <Atul.Luykx@esat.kuleuven.be<mailto:Atul.Luykx@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>>
Cc: 'Quynh' <Quynh.Dang@nist.gov<mailto:Quynh.Dang@nist.gov>>, IRTF CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the same: they are practically zero.  And, 2^-32 is an absolute chance in this case meaning that all attackers can’t improve their chance: no matter how much computational power the attacker has.

I don’t understand why the number 2^-60 is your special chosen number for this ? In your “theory”, 2^-112 would be in “higher” security than 2^-60.

Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>>
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
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.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I’m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
------
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls