Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

Ilari Liusvaara <> Sat, 25 April 2015 05:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 15B191A01AE for <>; Fri, 24 Apr 2015 22:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PW5GzXCqJI5Z for <>; Fri, 24 Apr 2015 22:35:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D5871A90A7 for <>; Fri, 24 Apr 2015 22:35:01 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id C4AE281811; Sat, 25 Apr 2015 08:34:58 +0300 (EEST)
Date: Sat, 25 Apr 2015 08:34:58 +0300
From: Ilari Liusvaara <>
To: Hugo Krawczyk <>
Message-ID: <20150425053458.GA28576@LK-Perkele-VII>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Apr 2015 05:35:05 -0000

On Fri, Apr 24, 2015 at 05:31:51PM -0400, Hugo Krawczyk wrote:
> Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response
> to recent emails (including those under the "HSM-friendly Key Computation"
> thread). I will not touch on anything specific to HSM or PKCS11 since I know
> little about these and the recent exchange on these issues has not helped me
> understanding these things any better (but rather confuse me more).

Actually, for me, that HSM thread actually clarified what the actual requirements
are (which lets one minimize distruption).

> Let me start with the issue of whether we should be using the HKDF-Extract and
> HKDF-Expand separately or only use HKDF as a single function (which internally
> operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the
> latter approach (single function) as it deals with HKDF as a black box.
> But there are also advantages to calling these two components separately, and
> TLS 1.3 provides some good examples for that. First, HKDF is built to output as
> many keys as needed from a single HKDF operation, but in TLS we are deriving
> multiple keys from the same keying material through separate applications of the
> expand part. In such a case it is more natural to apply extract once and apply
> expand several times (with different info fields!). For example, Master Secret
> is derived using a single Extract operation but it is then used in three
> different Expand operations for deriving other keys (application traffic keys,
> export master secret, and resumption master secret). Second, when one starts with
> a strong key then the Extract step can be skipped making it convenient to be
> able to call Expand directly. Third, it is convenient to call Expand directly as
> a PRF for computing the Finished message. Lastly, and not least, it makes the
> key derivation logic more explicit which helps conveying the rationale of each
> operation and helps those analyzing the protocol (now and in the future).

Some models derive even more things out of (handshake) MS, e.g. one model does:
- s2c_appMS.
- eMS
- Unique
- c2s_appMS.
- rPMS
> My recommendation is to keep the Extract and Expand separation for the moment,
> in particular due to the last point, so we can see more clearly the logic while
> still setting the missing details of the protocol. When the whole picture is
> clear we can revisit this point.
> On other issues:
> - This should be obvious but worth repeating: All calls to HKDF-Expand MUST use
>   a non-empty info field binding the derived key(s) to a unique context (in the
>   case of TLS this is usually a label and a cumulative session-hash).
> - It was suggested that the length of derived keys should be part of the input
>   to key expansion. If desired, this length can be entered through the info
>   field of HKDF but I would be very careful not to derive two different keys
>   where the only difference in the 'info' values is the key length. If the two
>   keys happen to be of the same length one would end up with two keys that are
>   identical.

Well, there would still be string input of what the key is (otherwise e.g. rPMS
and eMS might up ending being the same, which isn't desirable).

> - One of the emails raises the issue of using random salt, as recommended by RFC
>   5869. Note that the RFC recommendation also indicates that the salt value
>   should be something that is authenticated during the protocol, or otherwise it
>   can be selected by the adversary. This authentication needs to happen
>   independently of the key being derived using this salt. For example, one
>   should be careful not to incur in a circular logic, e.g. deriving a key
>   mackey=HKDF(salt, info) and then using mackey to authenticate the salt by
>   computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation
>   scheme does not use nonces as salt.

With fixed salts, the HKDF extract function is essentially H1(H2(x)), where
H1 and H2 are H, but with different (pseudorandom) IVs.

Also, handshake hashes are very hard to control to any significant degree (or
invoking HKDF with bad salt is the least of your worries).

E.g. Suppose prf-hash is 256-bit MD5-equivalent-security. The handshake
security just breaks catastrophically against active attacks (passive attacks
are another matter).

> - Another issue raised in recent email exchange is the way to merge the
>   semi-static value g^xs (where s is the semi-static server's private key and x
>   the ephemeral client's private key) with the ephemeral value g^xy.

"the semi-static server's private key"??? There is no "the key". There's the old
semi-static key (which may not be available), and the new semi-static key. And
the two may or may not be the same key, and those keys may not even be available.

Also, in certain conditions, not mixing in DH result with the old key actually
leads to an attack (mixing the new one does not help here).

Also, I heard some implementers complaining about mixing the new one, and after
calculating the time penalty, I can easily understand (it is pretty sizable).

>   This is done by first extracting a key from g^xs as PRK1=HKDF-extract(0,g^xs)
>   and then extracting PRK2=HKDF-extract(PRK1,g^xy).
>   Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random
>   oracle as needed in the proof of security. Then PRK2 is derived with salt=PRK2
>   for the following reason. If g^xs is not exposed (the typical case) then this
>   HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less
>   demanding property from HKDF).  If g^xs is revealed by compromise of the
>   server's semi static private key s (after the conclusion of the handshake, as
>   in the forward-secrecy setting), then PRK1 is actually an authenticated random
>   and non-secret salt so you use HKDF as a randomness extractor.
>   In other words, each use of HKDF uses the minimal cryptographic assumption one
>   can have depending on the context of derivation.

If it is the new one, it is not properly authenticated (have I mentioned how nasty
even capturing the proper assumptions is?).

> - Finally, there has been a long discussion related to the derivation of both
>   secret and non-secret material (the latter for IVs). I can't say how this
>   works with HSMs, PKCS11 or other standards, but from the cryptographic point
>   of view doing this "mixed" derivation of secret and non-secret values is
>   not a  problem as long as HMAC is not broken as a PRF.

Well, looks like that problem got sorted out (by getting the "HSM folks" to
actually state the actual requirements).