Return-Path: 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 1224F1B3296 for ; Thu, 23 Apr 2015 13:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QF-K-7ZTEyim for ; Thu, 23 Apr 2015 13:08:10 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809681B3292 for ; Thu, 23 Apr 2015 13:07:59 -0700 (PDT) Received: by wiun10 with SMTP id n10so104919530wiu.1 for ; Thu, 23 Apr 2015 13:07:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XFp98P8roTMOGqgfomr7C4HnkmDjv9FBpQGdvKkqqso=; b=eEXv5j+87B0hRryqRm8oRopsX4p7e87ZF0vz/guKylh4tFs8zqEgmQaEN2Ux+bCvTw GeaEHzNUblD2NU5a616tBE7vc4dkJaE6ZceSQlutxSHUa1IAdanO7NKqC61Eo0LIJgjp HdfuHyWomUBpYLza6BStPi7D2xKmwDyTs+3H0K4YZr6DlE3nntZ3LD72ndK1xwazRhW1 hC1Bopuz9BzpXdhehfKdiTFQ8pvcDBgKRw4HYiP6wZ2PlS2ix1/BqC1H1ysMqbnw2aGJ i0N1RpgLWMLqJIUHz6h2XL+cHtLYDk6jhXrbPli+k71HVSmECmEiASU04Q629NcXdwGm +siw== X-Gm-Message-State: ALoCoQlD+lrjvYkZL5Amy+XXsMvcAXmJo2OjsB8+kgaBJ96ZE39GRJvgLiCs8eB+/BIIkHmHxNa+ X-Received: by 10.194.86.101 with SMTP id o5mr9106293wjz.8.1429819678254; Thu, 23 Apr 2015 13:07:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Thu, 23 Apr 2015 13:07:17 -0700 (PDT) In-Reply-To: <553925F7.5010704@nthpermutation.com> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <553925F7.5010704@nthpermutation.com> From: Eric Rescorla Date: Thu, 23 Apr 2015 16:07:17 -0400 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=089e0102f35203fec0051469d638 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 20:08:13 -0000 --089e0102f35203fec0051469d638 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns wrote: > On 4/22/2015 7:03 PM, Eric Rescorla wrote: > > > > On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns > wrote: > >> On 4/22/2015 1:37 PM, Eric Rescorla wrote: >> >> If we're using HKDF-Extract, can we just key off different labels? >> >> -Ekr >> >> > Sorry, read that as "HKD-Expand". > > Actually, use HKDF as the term with no expand or extract suffix. > I discussed this extensively with Hugo and Hoeteck and their advice was to use them separately in a similar way to what's here (though they suggested a slightly different hierarchy which I have to edit in). Perhaps Hugo will weigh in as to the reasoning. -Ekr > Mike > > > > > > -Ekr > > >> Basically, no. >> >> The Extract function is really not designed to be used standalone but as >> a way of concentrating entropy for input to the expansion phase. Its >> dangerous to talk of these functions as separately callable. They are >> steps not separate functions. >> >> The extract step's only non-key input - salt - is not the same as the >> "info" input used in the expand phase - 'salt' is supposed to be missing or >> random, not a fixed string like a label. >> >> "info" is where the various labels go and that's only present in the >> expand phase. >> >> >> What you want to do is specify as part of the mixins (e.g. 'info' - e.g. >> the collection of label and context) a set of fields that describe 1) how >> the key stream is going to be broken up (eg. lengths of the sub keys), 2) >> what algorithms will use each of the parts of the key stream, and 3) >> whether or not those parts are allowed to be exported/extracted. >> >> A software module will basically ignore these because - really - its all >> the same memory although it should really make sure the key lengths and >> types matc. An HSM will look at these and be able to make policy decisions >> for protection of the segments (e.g. preventing export of material that was >> created to be non-exportable). >> >> Having all of these in the mixins means that the key stream expansion >> completely changes if ANY of these mixins change which in turn means that >> the various ways you can use to extract truly secret key material (as >> differentiated from exportable material) from an HSM using the currently >> defined mechanism can be eliminated. (I can explain my reasoning if >> necessary). >> >> >> Mike >> >> >> >> >> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara < >> ilari.liusvaara@elisanet.fi> wrote: >> >>> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: >>> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: >>> > > >>> > >There are other places in TLS that fundamentally need to (indirectly) >>> derive >>> > >public data out of secret key material. >>> > That's not a a problem. The problem is using the same mechanism to >>> derive >>> > the public data that we use to derive the keys. >>> > It's even OK to use the same secret key for both (from an HSM POV). >>> > >>> > What Michael is saying is that there are existing functions for both >>> KDF >>> > (secret material -> key) and Mac (secret material-> unique public >>> data). >>> > He's requesting that TLS not have it's own versions of these functions. >>> >>> So would using two different PRF functions, one for parts that don't >>> downgrade and another for parts that do downgrade (e.g. IV derivation, >>> unique / finished calculations, exporter calculations, etc..) solve the >>> issue? >>> >>> (Of course, the two functions should be closely related, so not to >>> annoy software implementations too much)... >>> >>> >>> -Ilari >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> >> _______________________________________________ >> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > --089e0102f35203fec0051469d638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 4/22/2015 7:03 PM, Eric Rescorla wrote:


On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 4/22/2015 1:37 PM, Eric Rescorla wrote:
If we're using HKDF-Extract, can w= e just key off different labels?

-Ekr

Sorry, read that as "HKD-Expand".
 Actually, use HKDF as the term with no expand or extract suffix.

I discussed this extensively with Hugo = and Hoeteck and their advice was to use
them separately in a simi= lar way to what's here (though they suggested a slightly
diff= erent hierarchy which I have to edit in). Perhaps Hugo will weigh in as to<= /div>
the reasoning.

-Ekr
=C2=A0
Mike





-Ekr


 Basically, no.

The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase.=C2=A0 Its dangerous to talk o= f these functions as separately callable.=C2=A0 They are step= s not separate functions.

=C2=A0The extract step's only non-key input - salt - is= not the same as the "info" input used in the expand p= hase - 'salt' is supposed to be missing or random,=C2=A0 n= ot a fixed string like a label.=C2=A0

"info" is where the various labels go and that= 9;s only present in the expand phase.


What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the collection of label and context)=C2=A0 a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc.=C2=A0 An H= SM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means=C2=A0 that the various wa= ys you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated.=C2=A0 (I can explain my reasoning if necessary)= .


Mike




On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <ilari.liusva= ara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundamentally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the same mechanism to derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV).
>
> What Michael is saying is that there are existing functions for both KDF
> (secret material -> key) and Mac (secret material-> unique public data). > He's requesting that TLS not have it's own versions of these functions.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls<= br> 



_______________________________________________
TLS mailing list
TLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@ietf.or= g
https://www.ietf.org/mailman/listinfo/tls




--089e0102f35203fec0051469d638--