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

Michael StJohns <> Wed, 22 April 2015 21:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C81821B2A8A for <>; Wed, 22 Apr 2015 14:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jNpzF0Ic77jw for <>; Wed, 22 Apr 2015 14:49:22 -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 3D6AD1B2A82 for <>; Wed, 22 Apr 2015 14:49:20 -0700 (PDT)
Received: by pacyx8 with SMTP id yx8so284096023pac.1 for <>; Wed, 22 Apr 2015 14:49:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=xAVPej94INsZ7WLAeL4BosNH6p59pM+S2cPfsh5yza4=; b=O/nJ2Gfx3HKmRpRBCJqmyEigWjIQg6l3ylmTo0kJvPd9lrlqgU95UiAkcX4FrHUU+Q WJu0AL9h1t1gIfWRY2r7q/JvAoUEtK1irhw2vdxho6SLL+kNdgpMgJXRHGWB+P7haSTe Lcit1V6T+wHcjRE0IKAK0N+7doIyYUWXPHiXeJ4hk4aXU6kaLAJcJ+LkYGJLgS5k6r7V N/ohKL6MOHkvP7A2QeRmRINbZf2JeH9WsKTZpNhVhm571f07SbjPDu53rT4KSj+3tPP2 eEaLzEsiIGc9KlbdjlvhdaVcmYclOPNHEQUF1lXKAmvn3nnXui0UismTVQ68K8bEbAwB XMcw==
X-Gm-Message-State: ALoCoQn90TPjCuvtyDgoG2e4uJlkaT3NY71q1EtQRt5iqgNf3Cp+x8W+WpkJnrMV8M+DHAvQVdAN
X-Received: by with SMTP id ej11mr19539835pdb.72.1429739359856; Wed, 22 Apr 2015 14:49:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id xm7sm6083453pac.28.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 14:49:19 -0700 (PDT)
Message-ID: <>
Date: Wed, 22 Apr 2015 17:49:28 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Sean Turner <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090207060204070302060304"
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: Wed, 22 Apr 2015 21:49:25 -0000

I'm top posting my own post....

Sean et al:

After spending a bit more time looking at things from the view point of 
HSMs and cryptographic isolation, I'm now of the opinion that HKDF 
shouldn't be specified.

The specific issue is the difference between HDKF step 2 and the 
SP800-108 expansion functions.   Cryptographically, these specifications 
are close to identical except for the inclusion of a mandatory length 
term in the mixin values.   Without this term, a key stream produced 
from the same mixins (e.g. same label, randoms etc) for the same master 
key will be identical regardless of the length of the output key(s).

E.g. if one call to the KDF has a target key of AES128 and another call 
to the KDF using the same master key and mixins has a target key of a 
single octet HMAC key, the first octet of the AES key will be identical 
to that single octet HMAC key.    Using this construct with increasingly 
longer HMAC keys (thanks to HMAC's impedance matching function) will 
eventually reveal each and every byte of the AES key.

In an HSM, there is no way to differentiate these two different KDF 
calls for legitimacy.

If the KDF mixes in the length of the to be output key material, then 
any change in the length of the requested key changes the entire key stream.

I see three different approaches to fix this - 1) specify the SP800-56C 
with SP800-108 HMAC, 2) add the length term to the HKDF RFC and 
republish it, 3) ensure one or more length terms are included in the 
"info" for ALL KDF calls for TLS and document why.


On 4/3/2015 1:45 AM, Michael StJohns wrote:
> On 4/2/2015 10:04 PM, Sean Turner wrote:
>> On Apr 02, 2015, at 20:22, Michael StJohns<>  wrote:
>>>   I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process).  It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments.
>> The pre-5869 draft was AD sponsored by Tim Polk.  The IETF LC can be found here:
> I saw that, but that's for Informational, not Standard.  Different bar.
>> We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647.
> Yup.  But considering that the difference between HKDF vs the 
> combination of SP800-56C plus SP800-108 section 5.2 is the placement 
> of the iteration value in what gets HMAC'd and the fact that _the HDKF 
> doesn't mix in the total length of the data to be output_,  I'd rather 
> use the latter cites if we could even if they require an extra 
> paragraph to describe the selected sizes of L and i and what goes in 
> to Label and Context (basically "info" by another name).
> AFAICT, the addition of the L of the output to the data HMAC'd is 
> there to force a change to the key stream if the length of the output 
> key stream changes and that's probably a good additional security 
> property.  Other than that, I would say that these are pretty much 
> identical in cryptographic composition.
> Lastly, I still have hopes one day to remove the requirement for the 
> dependency on a HASH function in the handshake and this construct 
> allows for a CMAC based MAC.
> Again - I can live with HKDF, but I'm unclear of why citing the RFC is 
> a better choice given the above comparison.
> Thanks - Mike
> ps - I will write the paragraph for SP800-56C/108 inclusion if you 
> want if we go that way.
>> spt