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

Hugo Krawczyk <> Mon, 11 May 2020 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4AF63A0D0B; Mon, 11 May 2020 14:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e09RsXwbIIQg; Mon, 11 May 2020 14:05:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6A1F3A0D09; Mon, 11 May 2020 14:05:06 -0700 (PDT)
Received: by with SMTP id o10so9147379ejn.10; Mon, 11 May 2020 14:05:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dm6fAL0+o/QvUyeYqrKPTRReLHZeMQHdwnvHHtbLH0w=; b=LDZLgQGJozzmtd4QbD/Ij+wh1Ein93YzcOGGAemNHocIAcwKhBNX23qKxRD7oADE6A K+s8yuoV/ui6PyoEZ83Wd73/cX7xGmtELH6Io6HZ9qCxgP7nTaUBdi/1YtDM4u79jfmd xLwDMMXKeD6btigLeynGFj9ZiQXAaRPXI6IaL1JY0UthRq4cHJL+aU3w838tX2RUeo41 ra8eDk3XgsjTa26rj83yKAqMhNUodQnwQTnNrtOSHO1JdGFYOQN77DSNPPbTrqDu/O2w tJhdrPlIVFleCu2HjCxVlBqiPoImxWyAI4kVOe6U0n6t0Pe0hoIoTp54To3sE9dEMjAb cf8g==
X-Gm-Message-State: AOAM532PhIRK5KDhFyormlHVcoyOfC/Vu17oLtIa7z9cV5wspbXrplmw DDYcsVzPfM5Yy4KgY0de8zWBN1FZnZohCHPIMc7YMMx1KEs=
X-Google-Smtp-Source: ABdhPJzXvs9o9u7OE0l8UxLA+fotWc7gNNWA7Y68pscf1YCNQzpiQuTzlvXhL/XfPYInOKEOaGVz2ew3i374eBNwsvQ=
X-Received: by 2002:a17:906:3cd:: with SMTP id c13mr171624eja.153.1589231105359; Mon, 11 May 2020 14:05:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Hugo Krawczyk <>
Date: Mon, 11 May 2020 17:04:37 -0400
Message-ID: <>
To: "Dang, Quynh H. (Fed)" <>
Cc: "Salz, Rich" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008041cd05a565b3a9"
Archived-At: <>
Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 May 2020 21:05:10 -0000

Hi Quynh, see a couple of remarks below,

On Mon, May 11, 2020 at 8:10 AM Dang, Quynh H. (Fed) <quynh.dang=> wrote:

> Hi Rich, Sean and all,
> 1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type
> shared secret. However, the first HKDF-Extract in the key schedule takes a
> PSK instead of a DH shared secret.

The whole point of HKDF is to define a KDF that can be applied to different
uses and settings for key derivation. A single KDF mechanism that can
address a DH setting as well as a PSK, or  anything else, with
functionalities of PRF, random oracle, randomness extraction, etc., and
with some theoretical basis. Btw, TLS 1.3 is an application where
essentially all these aspects of HKDF show up.

NIST has adopted the view of HKDF in a very general sense via
the standardization of the extract-then-expand approach at the basis of
HKDF . This applies equally to extracting entropy from a DH value, the
output of an RNG, a PSK, etc.

> We don't see security problems with this instance in TLS 1.3. NIST
> requires the PSK to have efficient amount of entropy (to achieve a security
> strength required by NIST) when it is externally generated. When it is
> externally generated, one of NIST's approved random bit generation methods
> in SP 800-90 series must be used.
> When the PSK is a resumption key, then its original key exchange and its
> key derivation function(s) must meet the security strength desired/required
> for the PSK.
> NIST plans to allow/approve the function in SP 800-133r2, Section 6.3,
> item # 3 on pages 22 and 23:
> 2) Traditionally, HKDF is extract-then-expand. However, in TLS 1.3, we
> have extract-then-multiple expands.

The HKDF RFC 5869 says that in the case where the amount of required key
bits, L, is no more than HashLen, one could use PRK directly as the OKM.

In the usage by TLS, you are using the output of extract as a key to a PRF
(implemented as HKDF-expand, essentially HMAC) with multiple, different
inputs (different thanks to the use of the info field) which is perfectly
secure. Also, note that the composition of the extract step in TLS with
each of the subsequent expands can be represented as a full HKDF
application. This was part of the design for cases (maybe  hardware) where
one may have an interface to HKDF but not a separate interface to
the extract and expand steps.

> We don't see security problems for this new version of HKDF as specified
> in TLS 1.3.  NIST plans to approve a general method for this approach in SP
> 800-56C revision 2, section 5.3:

Agreed. The above comment summarizes why there should be no security
problems with these mechanisms.

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


> NIST plans to handle the issues above that way to avoid repeating the work
> when one or both of the same HKDF instances or new variant(s) for one or
> both of them is/are used in different application(s).
> The other KDFs are already compliant with NIST's existing KDFs.
> Regards,
> Quynh.
> Recommendation for Key-Derivation Methods in Key-Establishment Schemes
> <>
> 23 . Draft NIST Special Publication 800-56C 24 . Revision 2 25
> Recommendation for Key-Derivation 26 . Methods in Key-Establishment Schemes
> 27 . 28 . 29 Elaine Barker 30 Lily Chen 31 Computer Security Division 32 .
> Information Technology Laboratory
> ------------------------------
> *From:* Cfrg <> on behalf of Salz, Rich <rsalz=
> *Sent:* Friday, May 8, 2020 4:21 PM
> *To:* <>; <>
> *Subject:* [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
> If you don’t care about FIPS-140, just delete this message, and avoid the
> temptation to argue how bad it is.
> NIST SP 800-56C (Recommendation for Key-Derivation Methods in
> Key-Establishment Schemes) is currently a draft in review. The document is
> at
> Email comments can be sent to with a deadline
> of May 15.  That is not a lot of time.  The NIST crypto group is currently
> unlikely to include HKDF, which means that TLS 1.3 would not be part of
> FIPS. The CMVP folks at NIST understand this, and agree that this would be
> bad; they are looking at adding it, perhaps via an Implementation Guidance
> update.
> If you have a view of HKDF (and perhaps TLS 1.3), I strongly encourage you
> to comment at the above address.  Please do not comment here. I know that
> many members of industry and academia have been involved with TLS 1.3, and
> performed security analysis of it. If you are one of those people, *please*
> send email and ask the NIST Crypto Team to reconsider.
> Thank you.
>         /r$
> _______________________________________________
> Cfrg mailing list
> <;;sdata=5DEzorMNakxeh%2Bkb4wYJ00QxyRmcXbsDFm7wlVw9iig%3D&amp;reserved=0>
> _______________________________________________
> Cfrg mailing list