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

Michael StJohns <> Fri, 03 April 2015 00:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ABE711A8908 for <>; Thu, 2 Apr 2015 17:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XUtYcUvEwHtH for <>; Thu, 2 Apr 2015 17:22:36 -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 E75BD1A8905 for <>; Thu, 2 Apr 2015 17:22:35 -0700 (PDT)
Received: by qcrf4 with SMTP id f4so67718934qcr.0 for <>; Thu, 02 Apr 2015 17:22:35 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Y5GFYukvctYVr76icp/MyZFcuAEKmBd2VLwnsDnLrFk=; b=cPFruHKyMy5UoVZHpHu60NhyKKQ1ReVEC8knVVKE5BGfjX/zPdPV2iuznRq1fMK795 xC3oXKKvRqBIMiAY7774urPTUwxXQOVUFRlOOYePPCxKKiiBxM/2MVL7x6kseOrBjA7D QpzDX844t4Q/O3RL3zOq6wXZDwi+lWklVWqwabMkHdDOkf50gDimgFxYSgZmahDW6m0b QURLna9ZnuBOno8eW2vsQYu2trff0FuU+SRVI2bdNIRB4G5EZMsheHu6BRXO8L7XYseR If94ijjVPvrWpvQ0QMhIJIjin6gPxyO8k/mJrgtC4W956XB3T1kT3OyoW/hSsYVvfmD/ mnOA==
X-Gm-Message-State: ALoCoQlv3ceFXs7lCsQ+IIVAB/aotdoDZ1lbMGVZNlRnzFZEtcs8nIQQGtl1a4A6jAxiF6C1Ssqx
X-Received: by with SMTP id z196mr65651021qhd.66.1428020555114; Thu, 02 Apr 2015 17:22:35 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:f827:63cf:7b05:550e? ([2601:a:2a00:84:f827:63cf:7b05:550e]) by with ESMTPSA id 138sm4608248qhx.7.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 17:22:34 -0700 (PDT)
Message-ID: <>
Date: Thu, 02 Apr 2015 20:22:38 -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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
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 00:22:37 -0000

On 4/1/2015 2:00 PM, Sean Turner wrote:
> This message is to confirm the consensus reached @ the IETF 92 TLS session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an HKDF-based PRF (see
> Please indicate whether or not you agree with the consensus by 2015-04-17.  If not, please indicate why.  Also, please note that we’re interested in uncovering new issues not rehashing issues already discussed.
> Thanks - J&S
> _______________________________________________
> TLS mailing list

I have a large preference to move to a different KDF than we're 
currently using. (And to limit the output of said KDF to key material 
and nothing else).  Deprecating the current TLS KDF will help with 
resolving some HSM related security issues.

I have a medium preference that that KDF be counter based rather than 
recursive (as is the current PRF and HKDF).  I've got a sneaking 
suspicion that doing so would be cleaner to implement in hardware as the 
only field changing with every call to HMAC is that of the counter.

I have a small preference that we cite a more widely accepted/reviewed 
standard than RFC5869 (which is basically the authors republication of 
their original paper or vice versa).  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.

I wish David et al had ended up completing the work on, but what's 
there suggests that we could select one of those instead and get a more 
widely acceptable KDF.

All that said, I won't oppose HKDF.