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

"\"Torsten Schütze\"" <Torsten.Schuetze@gmx.net> Tue, 12 May 2020 11:40 UTC

Return-Path: <Torsten.Schuetze@gmx.net>
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 7677D3A09C4; Tue, 12 May 2020 04:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 KaJm_R-RLlwd; Tue, 12 May 2020 04:40:09 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A6E3A099F; Tue, 12 May 2020 04:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589283598; bh=+gzZrmxhsFELRoZcHRA7kHUStsQdJHKE4dvv5NgJyco=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=FHiZVorQjDHwbN9kfMpRnFB7EbIIa9VriFZytAnD+OpRSWsZoeDTqoSvXcn01c0rH kkYwOQc4RndUMSihFYltt3xel9vtvH8fapl9wdJ7YuS93mpA4QYGC4CrqTUh2dxm75 K1jtU1sw6TUgCn2yOif8T5b10Kmmpxd/QIq3vQTI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [80.246.32.33] ([80.246.32.33]) by web-mail.gmx.net (3c-app-gmx-bs46.server.lan [172.19.170.98]) (via HTTP); Tue, 12 May 2020 13:39:58 +0200
MIME-Version: 1.0
Message-ID: <trinity-5bbd0a19-0945-419f-a806-5b2757ed2c42-1589283598300@3c-app-gmx-bs46>
From: =?UTF-8?Q?=22Torsten_Sch=C3=BCtze=22?= <Torsten.Schuetze@gmx.net>
To: "Hugo Krawczyk" <hugo@ee.technion.ac.il>
Cc: "Dang, Quynh H. (Fed)" <quynh.dang=40nist.gov@dmarc.ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>, "tls@ietf.org" <tls@ietf.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Content-Type: text/plain; charset=UTF-8
Date: Tue, 12 May 2020 13:39:58 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <CADi0yUMuV0U=YWB2cFMYRsitLHeWEaV2WM9XVTdKqDkOsyvaGA@mail.gmail.com>
References: <07D37E65-0951-49BB-B86E-BD3167ADB352@akamai.com> <BY5PR09MB4755E58AF9CDF696C0E7F649F3A10@BY5PR09MB4755.namprd09.prod.outlook.com> <CADi0yUMuV0U=YWB2cFMYRsitLHeWEaV2WM9XVTdKqDkOsyvaGA@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:i3QLHpDkUajaVwHuxpCjk1UIgUbXOzj1i0Ehwlwia3LyhLgEDXAO3UkxuLPzH0dSLBEsV aPIkrVaWusfo54O7W7I/FbiBZT3+x6g2q12EdQ0sHPhsfC2oUJLAo5EYWaezKtRH06WF/sgKfee9 1NvW6uVqG6/sriI6EE2rpkGcW3UlGebTjNPi/WTW4GhirAmfIbIluXc2ii95OcgiiG/EKhad0uiS moljg5DiI0uB/7xvKrtF/GCP4zjQIQ+JB1lhUgqNQe4FLAWT8Jpy0nuyckKszCTae73YPrIcL17k 9w=
X-UI-Out-Filterresults: notjunk:1;V03:K0:oxiSuBQagNE=:oOc1Ygk67yOKThfHcfOHor aBNbwqhRKcQI7BYY8qPQeu3EArh3fCdFjL6s0YdeuOQAOW7AjB7cujjrVLhf0OPwgr0CBPudO i9fdUU8L/6zjBkK0Lvpdh4+mxCwNVxKCMxxrCCTweMQMQtYU4rSJRQWQfrnIaO08/ZTlYGnyP 49i5ZhQPbb8e+nt3MALETkKXkJWACqrjujK4OmkwhLlz+g02TrjW1cdXGmqJIeIOFG1RwighE 3lyYzzq6Z0RvuNV5cbXS5FyhjjeQGb+iPCT4XAV8uz0wS6czWCWh2rKzWAbTF02xN2q6l3sFA jMG+mAa/O3rgetRycAJlUcoxGroop85JTA6BYydU1Sg2QGfLX1Kb9QMBnEsSpa2NGNTvcfN3j igLfoRUuvdB8dm7XH4Bqg13WdhUtMm4T7Vu4/SAdJ/s1u/tXoufAbek66bQ7X8RwFETAYeawM 8EIDoqHCFKVq9g63Ohxor6xOEOeeTZULBiwr1JdT3qYyu9E0rzBZJEpE7M1DGQdk41mIs6T3C Zrof8y3bml+y9lAiMUVtEp7pfm3UGVjAYdb8qe4HOAXvA7SkfCE8FcPbTqe5s2Ka5ScYOidto BnrDs1/S9ZeehQsZZOR4FK5nk/S/D3aRSNd3020eJlsDJbFzd7TRogov4XDXQYA1jBof9pCmm YOyQXx7mnRAJE0/02E14GE1PJwi43AdoYFZdmocHqQyIpsxLep0rzNZYBqZB+zMLc9nc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/PfyIgX1_vT-a1E1aVYC83wsEBhw>
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 11:40:10 -0000

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