Re: [TLS] HSM-friendly Key Computation
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 24 April 2015 17:53 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F8F1B310E for <tls@ietfa.amsl.com>; Fri, 24 Apr 2015 10:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHqzLxAXPYDK for <tls@ietfa.amsl.com>; Fri, 24 Apr 2015 10:53:49 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7550A1ACDDC for <tls@ietf.org>; Fri, 24 Apr 2015 10:53:49 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (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 <ilari.liusvaara@elisanet.fi>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20150424175346.GA25396@LK-Perkele-VII>
References: <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <CABcZeBPN33DM_C0sAmCTFCTdNrcQ7y7eEBcZgPe+2f1EaxtXzA@mail.gmail.com> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> <20150423175244.GA26942@LK-Perkele-VII> <55394191.1050203@nthpermutation.com> <CAOgPGoC4AcoQ1nSoqA20NSqnd1YXt=CTvLj2DVi6DXnxincJjg@mail.gmail.com> <CACsn0cm2cXgt1==r9DgK5a8ezOFx=4QMtwNB-sEyM17EgihbyQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CACsn0cm2cXgt1==r9DgK5a8ezOFx=4QMtwNB-sEyM17EgihbyQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Q31mgrFgZA_1ZH6z9D-B30u0Mpo>
Cc: tls@ietf.org
Subject: Re: [TLS] HSM-friendly Key Computation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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" <joe@salowey.net> 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 KDF. ("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. -Ilari
- [TLS] HSM-friendly Key Computation Russ Housley
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Martin Thomson
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Yoav Nir
- Re: [TLS] HSM-friendly Key Computation Brian Smith
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Peter Gutmann
- Re: [TLS] HSM-friendly Key Computation Benjamin Beurdouche
- Re: [TLS] HSM-friendly Key Computation Michael StJohns
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation StJohns, Michael
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Robert Relyea
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Michael StJohns
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Michael StJohns
- Re: [TLS] HSM-friendly Key Computation Michael StJohns
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Michael StJohns
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Eric Rescorla
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Joseph Salowey
- Re: [TLS] HSM-friendly Key Computation Watson Ladd
- Re: [TLS] HSM-friendly Key Computation Ilari Liusvaara
- Re: [TLS] HSM-friendly Key Computation Hugo Krawczyk