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

Watson Ladd <> Mon, 27 April 2015 00:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF2031AD09D for <>; Sun, 26 Apr 2015 17:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sl06qsl365L4 for <>; Sun, 26 Apr 2015 17:23:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00E001AD084 for <>; Sun, 26 Apr 2015 17:23:53 -0700 (PDT)
Received: by wizk4 with SMTP id k4so80476872wiz.1 for <>; Sun, 26 Apr 2015 17:23:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wlMJzccPp9+QHBlHBjtOgc3VpM+imOXODR1LLGhUjZY=; b=PTsYCfBOOdqqs2HS/CvIch3uWikEgPEfsp9ZHP6erv6oF0SVX45UJTSt6lEl1ZJn0e MTPMW9r0oB3TKEvtT5awRG+SwEaYO9D3DGOIgo+zIouVl3ziV5XePGzg8X/Oe+h8AyEw jvTd4/hR6V50w16oDVNe1PsAxNu0GHvdw0AELAZNT+k49gdjExuMRAE8m6SQZQumKsvI SkTvO9GDpsFyTZ4QW+EqOkg8Bwa2QvVr20xQft3xpKtcWeZaLMeYszdd8exT7okqgc4o Zwa0B8xth48WYcVq1kpc570Iw7FguPuG4WNjs3FWapspAmeO2AUpcIthOFDmgZqXidfU oC0g==
MIME-Version: 1.0
X-Received: by with SMTP id h1mr15930405wiy.26.1430094231644; Sun, 26 Apr 2015 17:23:51 -0700 (PDT)
Received: by with HTTP; Sun, 26 Apr 2015 17:23:51 -0700 (PDT)
Received: by with HTTP; Sun, 26 Apr 2015 17:23:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Sun, 26 Apr 2015 17:23:51 -0700
Message-ID: <>
From: Watson Ladd <>
To: Michael StJohns <>
Content-Type: multipart/alternative; boundary="f46d04426730ac2fe50514a9c27e"
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: Mon, 27 Apr 2015 00:23:55 -0000

On Apr 26, 2015 4:50 PM, "Michael StJohns" <> wrote:
> On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>>> TLS1.2 uses the Master secret as a key for both the MAC and KDF
functions and that needs to change.  Those can't be the same key - and
hence your comment about using the same master secret for different derives
becomes problematic especially if one of the outputs is to an exporter.
>> ​ The same Master Secret is used to derive multiple keys but these are
derived with unique label+context input.​
>> ​
>> ​ Different derivations *never* use the same label+context.​
> Next part of the discussion.
> Pretend you're implementing this in an HSM.  How does the HSM enforce the
"never use same label and context"?  Answer is that it can't and there
isn't anything currently defined in the label or context that allows the
HSM to do proper policy protection.
> What needs to happen here is to include in the calculation of the key
stream sufficient values to ensure the key stream is completely different
if the requested output (e.g. target keys and types) of the key stream is
> Consider as an HSM input to the TLS KDF the label "key expansion", the
handle for a specific master_secret key and the client and server randoms
concatenated as the context. Internally, the HSM will concatenate the label
and context into what you call "info".   The last set of inputs to the "key
expansion" call to the KDF are the types and output lengths of the key
material, but those aren't involved in the calculation of the key stream.
> If you call the HSM version of the KDF with a key, context and label and
tell it to break things into 2 keys (for AES-CCM) of length 256 bits each
you will produce a key stream of length 64 bytes.
> If I call the HSM version of the same KDF with the same key, context and
label and tell it to produce a single HMAC-SHA256 key of length 8 bits I
will get a single byte of key stream which is identical to your call
above.   Using the TLS 1.2 KDF I can even tell it to not produce any key
material but to provide me with IVs - which have the same key stream
material as from your call.  All because the length and types of the keys
to be produced are not mixed into the key stream production calculation.

But the context told you what key I wanted, and how I was going to use it.
Why is that easier to enforce then one time use? I'm also not sure why we
want to protect non cert keys in an HSM: the attacker can always use the
HSM to decrypt.

> If I define the TLS KDF as HKDF with a context consisting of (from my now
expired draft):
>    struct {
>        uint8    clientRandom[32];      /* ClientHello.random */
>        uint8    serverRandom[32];      /* ServerHello.random */
>        uint32   keyCount;              /* Num keys to derive */
>        KeyType  keyTypes[keycount];
>        uint16   keyLengths[keycount];  /* Key lengths in bits */
>    } KeyExpansionContext;
> the HSM can use the key types and lengths to enforce policy of key
assignment.  An attacker can no longer assign a part of the key stream to
shorter keys since the key stream changes if the length of any subkey
changes.  It can no longer assign a strong mechanism key to a weaker
mechanism because if the key type changes so does the key stream.    After
discussions on the list, I'd probably also add a uint16 of flags per key to
allow for some keys to be exported (and allow the HSM to know which ones
are exportable).
> There are other issues, but this gets us closer.
> Mike
> _______________________________________________
> TLS mailing list