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