Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ?
Andrei Popov <Andrei.Popov@microsoft.com> Wed, 24 February 2016 19:41 UTC
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6A1A8883 for <tls@ietfa.amsl.com>; Wed, 24 Feb 2016 11:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 EpC84395Oxm3 for <tls@ietfa.amsl.com>; Wed, 24 Feb 2016 11:41:18 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDD31B3E1F for <tls@ietf.org>; Wed, 24 Feb 2016 11:40:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o4Ie6JaW+aGUGWrlwqPuzQ/F2I6rSNWAkIvYyFI6yOo=; b=maHnUOPeaEBrHoX51hA+Pw1sjgekRcSqTCiQPkN+P/efZwpnsjil1V5W43XamKkp2uYZ8qRjrTRspDlFAlG4N+FadhQXpqB/WqHHABj7T9PK5wHWb+TcgkeuQv5fCyr0qIC7eW9Bd1QijSmIXQd3B43rihp6fl4ntluML74rcsc=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 19:40:37 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 19:40:37 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: =JeffH <Jeff.Hodges@KingsMountain.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
Thread-Topic: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ?
Thread-Index: AQHRbpq2w7vtZL/adUqDXJhUT+elNJ87lZNg
Date: Wed, 24 Feb 2016 19:40:36 +0000
Message-ID: <BLUPR03MB13964F213F975F75DBDB1D9E8CA50@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <56CCF9C8.1060905@KingsMountain.com>
In-Reply-To: <56CCF9C8.1060905@KingsMountain.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::1d2]
x-ms-office365-filtering-correlation-id: c4dfc7cc-b11e-47f1-dbc0-08d33d525eb0
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:wU2nLSHZizHztfMSZWr2sJhbitutJbdW0I60HMbcaDj/U1zJn1POHjfHXHWUg2LZalVVcu5Jleys7xPVGZpcMjH94vZa75zhnWueZhEmi+Q4d+tBnadNtrv/OHTus9rLFB/ES3CM/i9VBpU2LqBYeg==; 24:+w1wsSP5IcR3dGeag9K5akPXQiQHxc8uRdIAO+59/w97e++yevBHzj5eh57WG3MdVeDCmBxvC83VgKAv1X5TpT1V22QZgtSbpOktisSLEWE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395;
x-microsoft-antispam-prvs: <BLUPR03MB13951BC3FF305745F1F6D6C88CA50@BLUPR03MB1395.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395;
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(102836003)(586003)(6116002)(1096002)(33656002)(1220700001)(8990500004)(5005710100001)(10400500002)(10290500002)(5004730100002)(5008740100001)(2900100001)(5002640100001)(2906002)(2950100001)(5001770100001)(19580405001)(4326007)(15975445007)(92566002)(189998001)(74316001)(3280700002)(77096005)(5003600100002)(19580395003)(5001960100002)(86612001)(40100003)(76576001)(87936001)(122556002)(10090500001)(106116001)(11100500001)(99286002)(50986999)(54356999)(86362001)(76176999)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 19:40:37.2289 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wt_LxTroE04dFfjZGPpAxKGf3Ks>
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2016 19:41:22 -0000
Hi Jeff, Tls13-11 I-D is not very clear on this, but my reading is that exporter_secret is the TLS 1.3 version of the Keying Material Exporters. If this is correct, then there are two pieces currently missing: the ability to specify a custom label and the ability to mix in application context. I don't know where this should live; perhaps RFC 5705 will need to be updated once TLS 1.3 is sufficiently baked. I also presume that exporter_secret (or a similar construction defined in the updated RFC 5705) will become the recommended replacement for tls-unique. The 1.3 key schedule appears to be under discussion, so things might change. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of =JeffH Sent: Tuesday, February 23, 2016 4:31 PM To: Ilari Liusvaara <ilariliusvaara@welho.com> Cc: IETF TLS WG <tls@ietf.org> Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? Hi Ilari, Ilari replied on Wed, 17 Feb 2016: > On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote: >> Hi, >> >> RFC5705 section 4 "Exporter Definition" [1] states.. >> >> The exporter takes three input values: >> >> o a disambiguating label string, >> >> o a per-association context value provided by the application using >> the exporter, and >> >> o a length value. >> >> If no context is provided, it then computes: >> >> PRF(... >> )[length] >> >> If context is provided, it computes: >> >> PRF(... >> )[length] >> >> >> ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function) >> from TLS {1.0, 1.1, 1.3}. Since the PRF() is no longer defined in TLS >> 1.3, RFC5705 is incompatible with TLS 1.3, yes? [...the above question remains unanswered...] >> >> Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material >> exporter (KME) in S 7.1 step 8 [2].. >> >> 7.1. Key Schedule >> >> [...] >> >> 8. exporter_secret = HKDF-Expand-Label(master_secret, >> "exporter master secret", >> handshake_hash, L) >> [...] >> >> >> ..i.e., does the above step "8." effectively define the TLS 1.3 keying >> material exporter? >> > > Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably > the "master secret" used for calculations is exporter_secret. agreed -- that is what is being referred to in various msgs on the list as "EMS" (exporter master secret?) ? > However, just replacing the PRF in definition with the standard TLS 1.3 > PRF (HKDF) would leave those exporters using randoms, which aren't > explicitly used anywhere in TLS 1.3. hm, I'm not sure I understand. back on 8-Oct you mused on the below [1].. One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with: label: "TLS 1.3 tls-unqiue" context: No context Length: 256 And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some better way at handling both context and no context cases? In original RFC, those were different): tmp = HKDF-Extract(label, exporter_secret) output = HKDF-Expand(tmp, 0x01 | context, L) or (no context case) tmp = HKDF-Extract(label, exporter_secret) output = HKDF-Expand(tmp, <blank>, L) ..where "output" would apparently be the Exported Keying Material value, which seems plausible (modulo refining the Label). So I'm not sure where/what you meant by "using randoms" above... exporter_secret is not a "random", yes? =JeffH [1] https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2ftls%2fcurrent%2fmsg17924.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8kyi1lG2n6i4M40Uo2p%2bwA%2fi7in%2by1TcgiZcwZbXiIY%3d _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=24nM3SyRy4yzg3lznrwYx5ECzf3ZkJqkRcYWQwlJn20%3d