Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <> Fri, 24 April 2015 17:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6F8F1B310E for <>; Fri, 24 Apr 2015 10:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SHqzLxAXPYDK for <>; Fri, 24 Apr 2015 10:53:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7550A1ACDDC for <>; Fri, 24 Apr 2015 10:53:49 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 276094011; Fri, 24 Apr 2015 20:53:47 +0300 (EEST)
Date: Fri, 24 Apr 2015 20:53:46 +0300
From: Ilari Liusvaara <>
To: Watson Ladd <>
Message-ID: <20150424175346.GA25396@LK-Perkele-VII>
References: <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <> <> <20150423084201.GA21246@LK-Perkele-VII> <> <20150423175244.GA26942@LK-Perkele-VII> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Subject: Re: [TLS] HSM-friendly Key Computation
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, 24 Apr 2015 17:53:52 -0000

On Fri, Apr 24, 2015 at 10:28:32AM -0700, Watson Ladd wrote:
> On Apr 24, 2015 10:13 AM, "Joseph Salowey" <> wrote:
> >
> >
> >
> > [Joe] I've having trouble understanding what exactly you are designing
> > here, is it the interface to a specific HSM or is it the TLS 1.3 key
> > derivation or is it something else? I think we need to make sure that we
> > have the requirements defined for the TLS 1.3 key derivation.

It looks to boil down to designing how to encode inputs to the underlying

("looks", because I think I am just beginning to figure out what the heck
is actually wanted).

> > Its not clear to me what the problem is with just including the context
> > label, session hash and possibly length.   The context label would
> > differentiate between derived key material for different purposes.  For
> > example, public and private data would use different context labels.  One
> > would also probably want to include the cipher suite ID in the context
> > label for keys derived for encryption.

Well, in one mail, Mike says that context labels are not enough.

He apparently wants for KDF to take type(s), export flag(s) and length(s)
of key(s) to generate as parameters. And then stuff those to info/seed
field (along label and such).

Also, looks like he would prefer that different encryption algorithms
have different types (e.g. AES-GCM vs. Chacha20-Poly1305).

(Again, the comment above applies).

> The issue is the hardware has to enforce the usage of the derived keys. I
> think this will restrict our encoding significantly,  perhaps turning it
> into some bitfields. Asking hardware to understand context labels is going
> to make it not hardware anymore.

Well, most of the "Hardware" here is actually "software", just running on
special-purpose hardware.

> Of course, there are other approaches that offer most of the gains without
> these costs like separate fixed function terminators, or keeping only a few
> keys secret.

Fixed function terminators? Also, what keys to keep secret does not fix
things, since there are some fundamential secret->public derivations.