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

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Wed, 01 March 2017 18:44 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 9BE7C129663 for <tls@ietfa.amsl.com>; Wed, 1 Mar 2017 10:44:14 -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 e2Dj6W8saFdP for <tls@ietfa.amsl.com>; Wed, 1 Mar 2017 10:44:12 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0096.outbound.protection.outlook.com [23.103.201.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2639512965F for <tls@ietf.org>; Wed, 1 Mar 2017 10:44:12 -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=Uf0WwVwZLXEOzzDyvS1n84LjUz2/sxbZ8TNYd7onACs=; b=ueK2QWLTUHjThBj2ttyWpACac/RO4v+oIVDSc4jPYfQ7sZqLaCKH2oRKiwau3czDXA/zZ36LhAhzeYXvNXRjn+fSJ1dt60cvaHB75E0pSr32kt+2j3G93ejyIiv94ow1P51g33YcNlcYZhrM4PZ/kd0XTBGJH1xpviQTSxjD0Nc=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 18:44:10 +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.0933.016; Wed, 1 Mar 2017 18:44:09 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Watson Ladd <watsonbladd@gmail.com>, "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1KF/+8GA//+uQQCAAGYzgP//rheAgABVqwD//68bAAASdHaA//+uLQA=
Date: Wed, 01 Mar 2017 18:44:08 +0000
Message-ID: <D4DC7F7F.3122D%qdang@nist.gov>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <CY4PR09MB1464243342F19FCBE48C37E7F3550@CY4PR09MB1464.namprd09.prod.outlook.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <D4DC341D.311E1%qdang@nist.gov> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> <D4DC4473.311F2%qdang@nist.gov> <D4DC8CDB.8A84E%kenny.paterson@rhul.ac.uk> <D4DC48E2.31204%qdang@nist.gov> <CACsn0cmf1AN1roDpQykoVJgqC-rhvauVwSEvokG9wiCNkk==yw@mail.gmail.com>
In-Reply-To: <CACsn0cmf1AN1roDpQykoVJgqC-rhvauVwSEvokG9wiCNkk==yw@mail.gmail.com>
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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.105.150]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:cCFTDdcsJG7geALs0+m7jmfU+h/QYecWU5t2729P5fQt+Pxqra9c5yrM3nQTg8lH0cWmqpf09d6YaLvYytoJwwDeHLeD97Odtbqyghoknv9ZrbWjTEQah793uHLCKk7+BvMWXhFcJ+fm69g3FOGIFcjYbceRWTrKgwgRwhn164M3p8Zvcc/UxPqds/S/q4eIls93jypLoa2r33RxWiAbCHh3IodBgjoY3Z2GFASYeocqeuxzAEoE96ECTl5nbBHoT5dJ4PjX75C1GqSKzNjBe3Xa8EOnekNz713VIk5lj24i+KqygSSWTVONNptWCXVnZkO7hlMxTA8KBRYDJekpWA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39850400002)(39840400002)(39450400003)(39410400002)(377454003)(24454002)(99286003)(6512007)(2900100001)(66066001)(122556002)(189998001)(54896002)(54906002)(236005)(6306002)(39060400002)(8936002)(4001350100001)(2906002)(83506001)(76176999)(7906003)(77096006)(7736002)(6486002)(3660700001)(25786008)(50986999)(229853002)(8656002)(3280700002)(36756003)(38730400002)(6506006)(106116001)(5660300001)(6436002)(102836003)(53546006)(86362001)(92566002)(81166006)(54356999)(2950100002)(6246003)(8676002)(53936002)(3846002)(6116002)(4326008)(606005)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-office365-filtering-correlation-id: e53225a8-85d4-432d-1bed-08d460d2f261
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462;
x-microsoft-antispam-prvs: <CY4PR09MB146264EDAC0B44A006D67A38F3290@CY4PR09MB1462.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(266576461109395);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462;
x-forefront-prvs: 0233768B38
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D4DC7F7F3122Dqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 18:44:08.9829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1rwcW0yiuGd4iekhKmmwEPTCqCA>
Cc: "cfrg@irtf.org" <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, 01 Mar 2017 18:44:14 -0000


From: Watson Ladd <watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>>
Date: Wednesday, March 1, 2017 at 1:36 PM
To: 'Quynh' <Quynh.Dang@nist.gov<mailto:Quynh.Dang@nist.gov>>
Cc: "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>, "cfrg@irtf.org<mailto:cfrg@irtf.org>" <cfrg@irtf.org<mailto:cfrg@irtf.org>>, Aaron Zauner <azet@azet.org<mailto:azet@azet.org>>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk<mailto:Kenny.Paterson@rhul.ac.uk>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

That is not how HTTP works. Lots of records are small

OK. What is the percentage ? Even all records were small, providing a correct number would be a good thing. If someone wants to rekey a lot often, I am not suggesting against that.

Quynh.

because they result from small writes.

On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)" <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>> wrote:


From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk<mailto:Kenny.Paterson@rhul.ac.uk>>
Date: Wednesday, March 1, 2017 at 9:38 AM
To: 'Quynh' <Quynh.Dang@nist.gov<mailto:Quynh.Dang@nist.gov>>, Aaron Zauner <azet@azet.org<mailto:azet@azet.org>>
Cc: 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).

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
<tls-bounces@ietf.org<mailto:tls-bounces@ietf.org> on behalf of quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>> wrote:
From: Aaron Zauner <azet@azet.org<mailto:azet@azet.org>>
Date: Wednesday, March 1, 2017 at 9:24 AM
To: 'Quynh' <Quynh.Dang@nist.gov<mailto:Quynh.Dang@nist.gov>>
Cc: Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>>, "<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>, IRTF
CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).





On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>> wrote:
From: Aaron Zauner <azet@azet.org<mailto:azet@azet.org>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <Quynh.Dang@nist.gov<mailto:Quynh.Dang@nist.gov>>
Cc: Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>>, "<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>, IRTF
CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.dang@nist.gov<mailto:quynh.dang@nist.gov>>
wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option
a.
1) The data limit should be addressed in term of blocks, not records.
When the record size is not the full size, some user might not know
what to do. When the record size is 1 block, the limit of 2^24.5
blocks (records) is way too low unnecessarily for
the margin of 2^-60.  In that case, 2^34.5 1-block records is the
limit which still achieves the margin of 2^-60.
I respectfully disagree. TLS deals in records not in blocks, so in the
end any semantic change here will just confuse implementors, which
isn't a good idea in my opinion.
Over the discussion of the PRs, the preference was blocks.


I don't see a clear preference. I see Brian Smith suggested switching to
blocks to be more precise in a PR. But in general it seems to me that
"Option A" was preferred in this thread anyhow - so these PRs aren't
relevant? I'm not sure that text on key-usage
limits in blocks in a spec that fundamentally deals in records is less
confusing, quite the opposite (at least to me). As I pointed out
earlier: I strongly recommend that any changes to the spec are as clear
als possible to engineers (non-crypto/math people)
-- e.g. why the spec is suddenly dealing in blocks instead of records
et cetera. Again; I really don't see any reason to change text here - to
me all suggested changes are even more confusing.




Hi Aaron,


The  technical reasons I explained are reasons for using records. I don’t
see how that is confusing.


If you like records, then the record number = the total blocks / the
record size in blocks: this is simplest already.


That formula does not correctly compute how many records have been sent on
a connection, because the record size in blocks is variable, not constant.
You can modify it to get bounds on the total number of records sent, but
the bounds are sloppy because some records only consume 2 blocks (one for
encryption, one for masking in GHASH) while some consume far more.

It's simpler for an implementation to count how many records have been
sent on a connection .... by using the connection's sequence number. This
puts less burden on the implementation/implementer.

I think the record size is configurable and it does not change regularly in the same session (or connection).  Somebody corrects me here!

Quynh.



Cheers

Kenny




_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls