Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

"Dang, Quynh H. (Fed)" <quynh.dang@nist.gov> Tue, 12 May 2020 12:04 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 9B24C3A0442; Tue, 12 May 2020 05:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level:
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=nist.gov
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 ysvrY_NOumMi; Tue, 12 May 2020 05:04:47 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2121.outbound.protection.outlook.com [40.107.91.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519173A041A; Tue, 12 May 2020 05:04:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=labcTHzN6N261yxNPUSaiCjszkisMD8DLJyuQlOgSnyLOEt6sO1tDO77zzn73PrPfzFvelYMHsmpP8R4jluaQgGK6Y31i32sWSfzZLo/72jS9Q2ErJ0b9xgDKxHMNqqDX9wBnanNrEx1adGumCKoGdKTUr2o1eilWsUwbY/HwSyX9VIL4w4pSJANdEQQhm/0icnj3g/VTJgzI/G2/YuWpFi+vcUbaulBHcZiX7o+FhbtGS0Qn59u+vhRoYggbQqS8Q9vbw0eqvDywIdDIMxCcJKG/1pTwoIsBT/usoeSO2ZQi+5fNoyTmA6+QBcWga8PKs942mnC8z9+cTezEtT2+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IbTS4GF8ExEvwZrqHG9jqwQ4xxWNOIq/k3XMex3D3J4=; b=Z4s8MU5waAeSMpP5iCwDNbQL1Orizh3YAyekcJ7p449h1NvF8jskXJ+OWHbN8wK0CWpJXR31BDnZkTuO1I03aeCOEKRx5ogDIyqxBU9e1O09mUTDW6/3/EltCMLknPNuPbUCyGAhayxXEGo+dmZfPqHrfYWDfvG9hBEasN6Z4le90N+0zmsTzjJyLIGK+q28Kmxox2QSaVGUJu6JbYfyDQYLwkeCQNdT0/WupAPhIaRk/A8tLtvSufYP0EFug8y20UDuhbxgrS2wrLIOErqa+HHOak2vMPxOgyLjY6wo1rn29RnBt5HpFBEFZ8ZdjdESKuGEmQJaVWJLTL24mZmaUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IbTS4GF8ExEvwZrqHG9jqwQ4xxWNOIq/k3XMex3D3J4=; b=dbIAOe3mixRJE2lRKoOeGJ+NbhUooKKs8dHxsB7mW4hEdAYS6n4nZioe5gglNBv5Nmjj8jozQI64xVGG2KCDEe6uW5oFGniTnNoOBiOeKdVh/6Ih4BkVjPEHqdTtPrwcqEeAS6w7uBXS4qwISevEp2Jmwxt/adQWaJ7zRZIMaAY=
Received: from BY5PR09MB4755.namprd09.prod.outlook.com (2603:10b6:a03:24b::12) by BY5PR09MB5185.namprd09.prod.outlook.com (2603:10b6:a03:241::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Tue, 12 May 2020 12:04:44 +0000
Received: from BY5PR09MB4755.namprd09.prod.outlook.com ([fe80::91d8:62e0:40e6:15e]) by BY5PR09MB4755.namprd09.prod.outlook.com ([fe80::91d8:62e0:40e6:15e%2]) with mapi id 15.20.3000.016; Tue, 12 May 2020 12:04:44 +0000
From: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
To: =?utf-8?B?IlRvcnN0ZW4gU2Now7x0emUi?= <Torsten.Schuetze@gmx.net>, Hugo Krawczyk <hugo@ee.technion.ac.il>
CC: "cfrg@ietf.org" <cfrg@ietf.org>, "tls@ietf.org" <tls@ietf.org>, "rsalz@akamai.com" <rsalz@akamai.com>
Thread-Topic: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
Thread-Index: AQHWJXY75SUMYNJzo0q8VSbsRy8U7aiiv0STgAClXoCAAPSSAIAAAvp8
Date: Tue, 12 May 2020 12:04:44 +0000
Message-ID: <BY5PR09MB47550508109A23C190D4326CF3BE0@BY5PR09MB4755.namprd09.prod.outlook.com>
References: <07D37E65-0951-49BB-B86E-BD3167ADB352@akamai.com> <BY5PR09MB4755E58AF9CDF696C0E7F649F3A10@BY5PR09MB4755.namprd09.prod.outlook.com> <CADi0yUMuV0U=YWB2cFMYRsitLHeWEaV2WM9XVTdKqDkOsyvaGA@mail.gmail.com>, <trinity-5bbd0a19-0945-419f-a806-5b2757ed2c42-1589283598300@3c-app-gmx-bs46>
In-Reply-To: <trinity-5bbd0a19-0945-419f-a806-5b2757ed2c42-1589283598300@3c-app-gmx-bs46>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [132.163.220.162]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cec51e77-4243-476c-d407-08d7f66ca8ca
x-ms-traffictypediagnostic: BY5PR09MB5185:
x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr
x-microsoft-antispam-prvs: <BY5PR09MB5185B92F39F23F5A44F24365F3BE0@BY5PR09MB5185.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +JO70gmsgH+Y/uJniW5EM6A0Hb6/rNjN03Yvgp4Jds6SxsrNSlRZvjxtixzpK65+yU5ae20xZR2jiwqyY7K26vrXMkkXcRYwh6/aeGt8YMkb+QNx+EUab9+YtW7F9iBwLh/pxFgO+XLgYxcpgffWqooMK8aJzzf9bbmF+zjf6mp4jpF+WOojKrrc9hT5g4bgqgYfKxst7oRv7GDa/I1lM6CzW+5apZoZMgRuQewRJuOvbGqcKXeHmuJrg3vne/hkZjPqZkWUW2r0/OdOX73R2qWcgwZaxabRaYTul0s5FNH//I/MYlKguStCAggTHZ0CJ9vFR6K7UIKB8Bp7SWIGDQ4oFh5mrnE666pQz5qg0zE3YjG1ikPyABw6UoIHbB8y6uyLhr8czVAlq1DQMZNeYif6I8zIOFzyUhsDeAkgIrLQrKeCSKGGdWrid90YONdGHUu89ewmgvl7K939ajbbU82M9zoo10gDKwFqhY8Oxd29FdfUYPXWdutTl6k0KMXt43/WKr+BohkFP/OrBNeOI4nSHMzZkIn5+UesZynOmGiMCwvbMjsDBzQY7YwEw0K0QL+9C9aMosSzjHR8nu3NMj+3SP3qIMEPnWC/1qoCKpo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR09MB4755.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(366004)(39860400002)(396003)(136003)(33430700001)(66946007)(91956017)(110136005)(76116006)(316002)(19627405001)(2906002)(66476007)(86362001)(66556008)(66446008)(5660300002)(64756008)(8676002)(8936002)(7696005)(4326008)(53546011)(6506007)(26005)(186003)(55016002)(71200400001)(478600001)(9686003)(33656002)(83080400001)(166002)(66574014)(33440700001)(52536014)(54906003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: uDmloWkCe+ib9fi76HlLlkAPDRO8dqygx1UWEPo3m0LZ8inaFEKKbLL1lgjzo5aR5xdVNQNoGtQK1aIc9jxEjzZkracvHgRVC0ipLoeEHsGMHA0gCphxk1en4ABSGw9jw8N5QGn/MT+nGoFtluLOYn8niZbJZ5BAEXGmGl9sWlcMkTxPTJbB7VXuB0o3JUKwta/VdX7y/QcWU8WOWMHh9ROBIsHobuwA9L9kswsJr8RKlynNoT4FPUpQmGUHXed6Mntyr/xGZswp6u//qne18Sch9B4Yob1Xg+Lu6B1GwbUx7uK4t0za0LEQO8IHwTuG8WfXDcOm8gSVmTOTIttYoZ9dQAyHpsPhm+YNg4SyQBBQJcTecZWYJ4wPNKVZNxCbIjjY+31DuRwWsDSiW69s4zwN2SrrUwiaDjdXbiNoBr2mzWqxP6u/f6gmLKV1l3dJ7847i2BFNXPSLCfA3rEre9+uOUWQW+Vl06cCyuheyGcXnLpgNmvtIBe+XJ1uV2/m
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR09MB47550508109A23C190D4326CF3BE0BY5PR09MB4755namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: cec51e77-4243-476c-d407-08d7f66ca8ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 12:04:44.3287 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yx3Q6MOqjmXsO0CvN0j/9feoSplENZyYTTYfc5L1Fn5OXjt8aKSjxSfpw57D4wUI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB5185
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ogRr6ZB5E4MN0WngaGrhVGjqDMQ>
Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Tue, 12 May 2020 12:04:50 -0000

Hi Torsten,

Thank you for the review. I think the review helps many people to understand the HKDF's spec and its NIST's approval better.

In SP 800-108 (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf, at the end of Section 5. (before 5.1), it says that "  Alternative orders for the input data fields may be used
for different KDFs. " .

And, at the end of the paragraph before that, it says "
One or more of these fixed input data fields may be omitted unless required for
certain purposes as discussed in Section 7.5 and Section 7.6.".

After an extraction step, the output is a pseudorandom key. The KDFs in SP 800-108 are NIST's approved KDFs to derive key(s) from a pseudorandom key.  The purpose of any of these KDFs in SP 800-108 is the same with the purpose of the expansion step. Therefore, they are allowed for being used as expansion steps.

Regards,
Quynh.


________________________________
From: "Torsten Schütze" <Torsten.Schuetze@gmx.net>
Sent: Tuesday, May 12, 2020 7:39 AM
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Cc: Dang, Quynh H. (Fed) <quynh.dang@nist.gov>ov>; cfrg@ietf.org <cfrg@ietf.org>rg>; tls@ietf.org <tls@ietf.org>rg>; rsalz@akamai.com <rsalz@akamai.com>
Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

Hi Hugo, hi Quynh,

on Monday, 2020-05-11 Hugo Krawzcyk wrote:

> I haven't looked at the revisions. But in previous versions you needed lawyer skills to go through the language to see that RFC 5869 was indeed compliant with the NIST recommendation. It would be nice if this time it would make very explicit that RFC 5869 is compliant with this Recommendation.

Indeed. In SP800-56C Rev. 2 draft we have in lines 545, 546:

"[RFC 5869] specifies a version of the above extraction-then-expansion key-derivation procedure using HMAC for both the extraction and expansion steps."  so one would assume that HKDF according to RFC 5869 is compliant with SP800-56CR2.

However, for key expansion it refers in line 533, 532 to

"2. Call KDF( K_DK, L, {IV,} FixedInfo ) to obtain DerivedKeyingMaterial or an error indicator (see [SP 800-108] for details)."

Everything would be fine if we find KDF( K_DK, L, {IV}, FixedInfo) as

HKDF-Expand(PRK, info, L) -> OKM

The output OKM is calculated as follows:

   N = ceil(L/HashLen)
   T = T(1) | T(2) | T(3) | ... | T(N)
   OKM = first L octets of T

   where:
   T(0) = empty string (zero length)
   T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
   T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
   T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)

i.e. the definitions of RFC 5869 in SP800-108. Unfortunately, the closest one could find in SP800-108 is

5.2 KDF in Feedback Mode

1.  n: = \ceil{L/h}.
2.  If n > 2^{32} -1, then indicate an error and stop.
3.  result(0):= ∅ and K(0):= IV.
4.  For i = 1 to n, do
    a.
        K(i) := PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2)
    b.
        result(i) := result(i-1) || K(i)
5. Return: K_O := the leftmost L bits of result(n).

With the substitutions PRK = KI, HashLen = h, N = n, T(i) = K(i-1) 0x01, 0x02 = [i]_2, PKM = K_O and info = Label || 0x00 || Context || [L]_2 one is almost there, EXCEPT

- the counter 0x01, 0x02, 0x03 is at the end of the string in HKDF RFC 5869 and right-after the K(i-1), respectively T(i), in SP800-108. At least this gives different results. (This is what already Dan Brown wrote in a recent mail). I don't think this has security implications, but I'm no expert.

- With HKDF, it is only allowed to iterate up to N = 255 as L \le 255 HashLen while in SP800-108 we have n \le 2^{32}-1.

So, with this interpretation I don't see that HKDF RFC5869 is a concrete instantiation of SP800-56C rev2 draft + SP800-108. At least I couldn't find any official CAVP test vectors for such an HKDF-HMAC-SHA-256 construct. BTW, while we have such test vectors in RFC 5869 for SHA-384 (and SHA-1) there are no such things for SHA-384 or SHA-512, i.e. higher security levels. As a practitioner I would first test my HKDF RFC 5869 implementation if it is allows to iterate above N = 255. BTW, I don't have a good feeling with extracting up to 2^{32}-1 keys from a single IKM.

I would like to hear from NIST if there are any plans to provide CAVP test vectors for HKDF-HMAC-SHA-2 according to RFC 5869. In my opinion, SP800-56C rev2 draft is suboptimal as it refers for a very important component, i.e. key expansion, to another, quite old document.

Torsten