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

Michael StJohns <> Sun, 26 April 2015 20:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 508831A90EC for <>; Sun, 26 Apr 2015 13:52:11 -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 efAqZwU7-1zb for <>; Sun, 26 Apr 2015 13:52:09 -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 7AAC91A90CD for <>; Sun, 26 Apr 2015 13:52:09 -0700 (PDT)
Received: by vnbg62 with SMTP id g62so9673687vnb.6 for <>; Sun, 26 Apr 2015 13:52:08 -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=VT3IA+q6MfJL9FBznjYXcXxHj/LkRft10ZqHawGH31E=; b=B9s52WsHtHE3H3g3pQTh14nwKb9qwiSjTJLypOeu5AzAR7iZoR+c+TsiLEZ7Cjyhcd Xx2vnY/rcKIjyXwc/bzuehUbN1eWHAuNGj8/4IuxqHPcLTSoAzmdtzCCyX1d/j5HOmmS upbkYGy+wXGrO1Y8NOtFtwkpnwGayCcwhevA1iVxxkhrQVEPKqxqBbnnwvNRFr0GKz9U k4Db+E2v8qJE2u1+eDn7qYfuF4asuTOZEsoYQ9iHlMCw7Ms4sqDIRgkftlLKUYScWnyd 8VOZbQywZQLPKsRwRJHdb1YDeWAxWr7iO30TG3/scqgFfM05AqqnvUeiZeXoQoUjoe+q DXGw==
X-Gm-Message-State: ALoCoQkTZ79DeYyEc1WcJSXVUPJ8lpTewkiu0DQTbrelry0OzgKq4Kts+u7dm8PGBEr9P9mV1m/v
X-Received: by with SMTP id py2mr20248427vdb.75.1430081528636; Sun, 26 Apr 2015 13:52:08 -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 x11sm20375714vds.25.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 13:52:08 -0700 (PDT)
Message-ID: <>
Date: Sun, 26 Apr 2015 16:52:07 -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="------------090500020809070600000109"
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: Sun, 26 Apr 2015 20:52:11 -0000

I'm going to slice this up a bit and answer in pieces.  Sorry - the 
messages are getting too long.

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
> ​I am completely lost on this length issue. Can you give me a concrete 
> example where TLS 1.3 derives different keys with same label and 
> context but with different output lengths? As said, in TLS 1.3 each 
> label and context is used exactly once. I must be missing something in 
> your argument but I just can't figure what's that.

Hi Hugo -

This isn't about TLS specifically, but about how an HSM makes sure an 
attacker can't extract TLS keys.

Assume that you implement your function in an HSM as you've defined in 
the RFC - without the length term.

Consider that the HSM keys may be USED by the attacker but the HSM is 
set up to prevent extraction - the keys can't be directly extracted . 
(See below for a discussion of how this might happen). And note that for 
a generic KDF interface, you can't ensure that the attacker doesn't use 
the same label and context in his call to use the master key as we 
define for TLS.

Consider that the derivation of the master secret from the pre-master 
secret can be done by both the user and the attacker, but that the 
attacker can request a key length of 1, but with the same label and 
context terms using the same pre-master secret.  Consider that the 
attacker designates this Length 1 key as an HMAC key.

The attacker now uses his version of the derived key as an HMAC key and 
uses it to generate an HMAC tag over a fixed value.  He then compares 
this to 256 generated HMACs over the same fixed value but using the 256 
different possible values of the derived key from above.  When he finds 
a match between one of his 256 HMACs and the HMAC using the derived key, 
he now knows that the value of that derived key.

Consider that _without the length term, a key of length 1 has as its key 
value the same first byte of any key stream of longer length generated 
from the same master key with the same label and context_.

By repeating the steps above, you can extract the master secret in O(1).

If the L term is mixed in by internal mechanism, there is no user 
accessible mechanism to accomplish this.  I.e. using the same secret 
with identical labels and contexts with differing requested output 
lengths produce cryptographically disjoint key material.    If you only 
pass this in as user specified material you don't get this protection.

If you ask me how an attacker can "use" the keys of someone else, 
consider that most versions of PKCS11 support only a PIN based 
authentication, or authentication is done because the HSM is embedded in 
the system.  The thing I'm trying to get to is a model where I can 
demonstrate that key material may not be extracted from an HSM by an 
attacker, even if the attacker has credentials to "use" the keys.