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

Andrey Jivsov <> Sat, 25 April 2015 05:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC4651ACF1D for <>; Fri, 24 Apr 2015 22:59:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lAY1HtdxPY59 for <>; Fri, 24 Apr 2015 22:59:55 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77EF61ACF1A for <>; Fri, 24 Apr 2015 22:59:55 -0700 (PDT)
Received: from ([]) by with comcast id L5zu1q0015AAYLo015zuKp; Sat, 25 Apr 2015 05:59:54 +0000
Received: from [] ([]) by with comcast id L5zt1q00M4uhcbK015zuP1; Sat, 25 Apr 2015 05:59:54 +0000
Message-ID: <>
Date: Fri, 24 Apr 2015 22:59:53 -0700
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <20150425053458.GA28576@LK-Perkele-VII>
In-Reply-To: <20150425053458.GA28576@LK-Perkele-VII>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1429941594; bh=1cSK6WM9E6cQ4fNOMiceYW1JW4qlhtN59cTKQ7hsvDY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mCcBgURFw9BZc7WCz6nJ+GxfXoGL8E37sUffFATUAuD7qYf5Jixb8gv27xs32BNmc HpNAxg8ikX6f9Z0LSkeRMqt5bFYJh6khmEkKhD/1Tr3prAPRRA9MzN5/p8U1gpEsgi FRYODJaQFgn1ZdXnvsEbwNTISUhllZD049AdkF2x11uiELl6Kf91orcgVvQlxmzDcz 9od4PFIbGnZNkCzaYTQ+cG93X0UcpPOsBgaTo4WxvuasQHnVVu6m96dwo7Eao00uiM 3pno6dt+ujG97JHMGRh0NH3CEVIzLnTs4KIJ+v9jZr4CgMheWCQA5G+DhutIPB43WT 9ThudpX7IMt0Q==
Archived-At: <>
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:59:57 -0000

On 04/24/2015 10:34 PM, Ilari Liusvaara wrote:
> 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.

Ilari beat me on this, but I also made this observation. In more details:

According to intended use of HKDF, HKDF-Extract is this:

    HMS = HKDF-Extract( salt=0, IKM=g^xy )

Which is:

    A. HMAC( 0, g^xy ) = Hash( opad || Hash( ipad || g^xy ) ).

The two invocations of the Hash() begin with hashing fixed values, so 
one can re-write the A as

    A1: Hash1( Hash2( g^xy ) ),

which can be rewritten as

    A2: Hash3( g^xy ) = Hash( opad || Hash( ipad || g^xy ) )

Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic 
hash of g^xy and that's the only contribution of g^xy in HKDF.

For comparison, TLS 1.2 does the following in the first step:

    B. Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "master secret" + 
ClientHello.random + ServerHello.random) ) );

It would be amusing to see a case when A2 is secure, while B is not.

> 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).
> -Ilari
> _______________________________________________
> TLS mailing list