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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EBE441B2CB2 for <>; Sun, 26 Apr 2015 17:59:24 -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 FUVoJkkWniCg for <>; Sun, 26 Apr 2015 17:59:23 -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 884721B2CAD for <>; Sun, 26 Apr 2015 17:59:23 -0700 (PDT)
Received: by vnbf1 with SMTP id f1so10174748vnb.0 for <>; Sun, 26 Apr 2015 17:59:22 -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 :content-transfer-encoding; bh=DhbdtjkKJd3BCAgzju0TICP/tHOzSk/qJdmVZDaZO+g=; b=esajAdA0GwBAyv80ChsNjYc1jbNOMr2ZqyscouuEI4ia+KmzEkBhAc4aim1zJB0L7d E5gW4flDfD+9c5fqpCgM0ZGxXUNT0eMeDdfaDRqA+DURDbGA2QitaCCzDdEr5EjhsRyu cn/0vpWIYQlDjvhtxSc6ZyEwD2FYhRJPJG7Ezivx/ZPqK/ze4PX70Nb+hwyz+lyt8u2f WS6JGDXgafl9LhfBO1fM2DBtNnyx0haaoBLoXRthHNmMO/P9VYI/hxKZna6gIGLkRaC8 S8iT9FPhDRSn73s6l5ghRNlNT8qYbppurHqx2DGoNAisu7KM2oYOzZWGAZzqWYerlkqM cIfQ==
X-Gm-Message-State: ALoCoQlJFsNcXLWOPQdqrDM4l7qdo4mLVh1Tdsv+FuZQIwiSKWPQCV1cBY0+OK2NjQ7YZVcQ75By
X-Received: by with SMTP id pj19mr19280503vdb.94.1430096362834; Sun, 26 Apr 2015 17:59:22 -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 ms8sm21793287vdb.21.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:59:22 -0700 (PDT)
Message-ID: <>
Date: Sun, 26 Apr 2015 20:59:20 -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: Watson Ladd <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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:59:25 -0000

On 4/26/2015 8:23 PM, Watson Ladd wrote:
> > 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.

This is a good question from a different direction.

In general, HSMs don't do "one time use" except as buried inside 
compound functions (e.g. the fake key pair inside an ECDSA signature).  
And it may be difficult to ensure the key is zeroized before an attacker 
can use it.    I'd rather not depend on ephemeralness as I expect 
different HSM implementations to deal with that differently.   Doing it 
by getting the derivation process correct stands a better chance of 
getting good implementations in HSMs.

In the current model, the context says how the user wants to use the 
key, but it doesn't constrain the HSM to use it that way or even to 
constrain it to produce a specific type and length of key - those are 
user inputs.  And in TLS1.2 and before the master_secret is used 
multiple times.

To the HSM, current TLS context is opaque unstructured data that gets 
mixed in without affecting the key stream to key assignment process.

With respect to protecting non-cert keys:  think about extracting the 
master secret and using steganography to hide it inside a picture on 
non-encrypted side of the server (or even the encrypted side if publicly 
available).  An attacker can retrieve that, capture the traffic stream 
externally, derive the session keys and capture the traffic safely 
remote without the betraying large amount of stolen data wandering past 
the server interface.  The attack can even forge data in the stream.  
This is obviously a made up example, but it was the first way I thought 
of using this - but consider that if an attacker can extract the master 
secret he can send it off to someone who can read the stream externally 
either in real time or later.

Later, Mike