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

Michael StJohns <> Fri, 03 April 2015 05:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CAD0D1A90BC for <>; Thu, 2 Apr 2015 22:45:49 -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 e3DZsP2EwsQJ for <>; Thu, 2 Apr 2015 22:45:48 -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 C4FC91A8F4A for <>; Thu, 2 Apr 2015 22:45:47 -0700 (PDT)
Received: by qcrf4 with SMTP id f4so71185717qcr.0 for <>; Thu, 02 Apr 2015 22:45:47 -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=gAclu5cfMHgZR2zY1HHZqYTmOvnrcsxeDrDBcmAxoak=; b=Ze1ao+GRRiXLx3wcemRvWkL3tlVYnMsNZpPOW4GWFViUNDCsH1ZpJtR/7KBw5PA1gt 33mYLEa6oIUcLEt7qmFYREuannb+aPpY5ZFtLpN0Fyb72lvoDEC9Vuks4GnkmC0k9B3O Cs9Ig8ewVrP0ihRtl3I6uDzkOUxkyQvyY3g2p+vJ+YebLKS6zrAd8LfCyPgo1vpp1ORE 1c0zVrHaIL/3pcyrF+sz0gSZ10tDOGd+6/K58J2VacDMVoGKpopHGqwo8et9vA7Wkopx Q2LCEXLKCna9Zk90jiG7wWywbqbkQTQFMrg4YIj5PqVhaAkrltgdqNrNGvNoiXaKv20m DFCA==
X-Gm-Message-State: ALoCoQnawqx8KfnyxDf2K11iwu0BzEYVyVW/wa/xxbT1gVzzwL4wHg3SX05WE11GPlM6EfgiBYow
X-Received: by with SMTP id e3mr957087qhc.94.1428039946908; Thu, 02 Apr 2015 22:45:46 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:7d17:2073:7e:bad2? ([2601:a:2a00:84:7d17:2073:7e:bad2]) by with ESMTPSA id p18sm5056088qkh.10.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 22:45:46 -0700 (PDT)
Message-ID: <>
Date: Fri, 03 Apr 2015 01:45:49 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Sean Turner <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050300020706090507080208"
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: Fri, 03 Apr 2015 05:45:50 -0000

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