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

Michael StJohns <> Mon, 27 April 2015 00:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 776461B2AAE for <>; Sun, 26 Apr 2015 17:30:01 -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 6QHN_9wizzmk for <>; Sun, 26 Apr 2015 17:29:59 -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 885181B2AAC for <>; Sun, 26 Apr 2015 17:29:59 -0700 (PDT)
Received: by vnbg62 with SMTP id g62so10076204vnb.7 for <>; Sun, 26 Apr 2015 17:29:58 -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=yq50hbU/m+1rDDC7ejPC5HSxXSeRJlTBtTPZWWXZbxY=; b=beW/uinrS8qdM+SEo5ZIK0/HYs9WIgI93c9WbgQOvYi2NUyH6S9V6puydjsayh+pqO 2qyc6bLz6VCKctT19rCONSbY5cy0xfGsY6asZeKT5AXXYgl3Hjn3v7oxhnXmpOGoRJcH d4nTLVz8i5Py7Ed4sZXf5ynoHzZiVVXqFNFpCDP5i6bq7fPhl2e90UUWlVWudKjO3DuE 8Yw/dfrYeclyO95e2E90kEL9Sx8nz4SgQfZfdadto8+Iv7cXquqBjzw9nhgYSlpUc9O4 3mr7O4eVON2S9/R2cBftl3YDkyMjpWnc6aOhj8ip7Bafu5vZel5CvB8wbte/g1nnpvXr Ctmw==
X-Gm-Message-State: ALoCoQn/NIzhAXVYNUd5PFUF3TMvj90AoV2JyWXLG1T99+DUUU4Z1Bv3+vabGGlcFuOI34kvW8iP
X-Received: by with SMTP id 10mr21864737vdy.74.1430094598712; Sun, 26 Apr 2015 17:29:58 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by with ESMTPSA id cl11sm21636380vdb.15.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:29:58 -0700 (PDT)
Message-ID: <>
Date: Sun, 26 Apr 2015 20:29:57 -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: Hugo Krawczyk <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090301090009090109000609"
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: Mon, 27 Apr 2015 00:30:01 -0000

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>     Given SP800-108 and SP800-56C were published before your paper 
>     and the RFC and have pretty much identical math (except as I
>     noted), why shouldn't we use those cites instead of the RFC?  E.g.
>     is there any cryptographic improvement in RFC5869 vs the other two?
> ​ SP 800-108 is a framework and set of recommendations, not a 
> specific, unique KDF function. HKDF follows this framework and NIST 
> found this sufficiently important to document this in a separate 
> document SP 800-56C (which explicitly includes HKDF as an instantiation)​
> ​ .​

You didn't actually answer the base question of "is there any 
cryptographic improvement...."?

With respect to the above, SP800-56C says to use one of the SP800-108 

Third paragraph of section 4 of SP800-56C:
> The key expansion step uses the key derivation key KDK and other 
> information exchanged and/or pre-shared, such as identifiers for the 
> involved parties, protocol identifiers, and the labels of the derived 
> keys, as the input to an approved key derivation function specified in 
> SP 800-108 [4] to produce secret keying material KM of a desired length L.

What I think you're referring to is (last paragraph of the same section):
> IETF RFC 5869 [10] describes an instantiation of the above 
> extraction-then-expansion key derivation procedure using HMAC for the 
> extraction and expansion steps. For extensive rationale on the key 
> derivation through the extraction-then-expansion procedure specified 
> in this Recommendation see [11].

But that appears to be a reference to base material rather than an 
endorsement of it as an approved function.

Cryptographically, there isn't any difference I can see except the L term.

If I were to do this I would say in TLS:

"The TLS KDF is the extraction function specified in SP800-56C combined 
with the "KDF in Feedback Mode" mode (Section 5.1) of SP800-108 with the 
following specifications:  For SP800-56C, the shall be no salt and the 
extraction function shall be as appropriate for the selected TLS PRF.  
For SP800-108, the KDF PRF shall be the MAC function of the selected TLS 
PRF with a default of HMAC-SHA256. The L and i terms shall be expressed 
as network byte order 32 bit unsigned integers.  The Label shall be the 
defined TLS label expressed as ASCII bytes, and the Context shall be the 
context defined for that specific Label encoded as per normal TLS rules. 
The ordering of the terms processed by the PRF in step 4a is as 
indicated in SP800-108 section 5.1."

Later, Mike