Re: [TLS] HSM-friendly Key Computation

Eric Rescorla <ekr@rtfm.com> Thu, 23 April 2015 20:06 UTC

Return-Path: <ekr@rtfm.com>
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 522391B3279 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 13:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 vIF3SSTHSo97 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 13:06:50 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 ED31D1B326B for <tls@ietf.org>; Thu, 23 Apr 2015 13:06:33 -0700 (PDT)
Received: by wiun10 with SMTP id n10so104881753wiu.1 for <tls@ietf.org>; Thu, 23 Apr 2015 13:06:32 -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=vWu975+24lPlECqQduenP9tt/VlcAqWRYHuYQXS90FM=; b=UBkT4gUh3lo3WA8kznotw8BQNFdCwULMcpEK3hDsjX1wG8u4zNshjZlU0ABIwkDDRk 4vOUaN6k4ofXp83mFN92w/rMnsht12kr5x3Vq4Nluo/KusJDbtYX2BeE1QGaVoRhZpds wgTHHLvxHZr+TeT1TK74PiLP2gkA5SEwKTeqFjHuoXdOB+Lysihtk2IHpPlliALe8i1c 3ZckX6MHQS29M4sO82mjadwzHhYINV298+LwnGyAO0auzv65mfl1bxpjLO2vZeNGjGkA 2LVyVscb+iIirNRNVmTsBtjwVKgHVDK7uW9DZ4EGSsZEEtT7Rz8MLhBRGLqCHplRUP5r Oy1A==
X-Gm-Message-State: ALoCoQmBrtykVfDyJIevccPRwf64WmHlDuyOmebdW6AcRB26N9tsp0bes0CW5+BJqlhtWbh9F4zc
X-Received: by 10.194.59.79 with SMTP id x15mr8662063wjq.81.1429819592673; Thu, 23 Apr 2015 13:06:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.87 with HTTP; Thu, 23 Apr 2015 13:05:52 -0700 (PDT)
In-Reply-To: <20150423110214.GA21716@LK-Perkele-VII>
References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <CANeU+ZAL6oT6tP7OcL_8j6kp4oZB9V89R-0PrCdv-N27qVb0HQ@mail.gmail.com> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <CABcZeBPN33DM_C0sAmCTFCTdNrcQ7y7eEBcZgPe+2f1EaxtXzA@mail.gmail.com> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <CABcZeBMcy_C0TWgOfw6480ZV28GTfEsgABf5b9-hKPbRGkTCMQ@mail.gmail.com> <20150423110214.GA21716@LK-Perkele-VII>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 23 Apr 2015 16:05:52 -0400
Message-ID: <CABcZeBNPmssXgLW70Kk+v3rELaYbar_rkdDZAexYoshXoDAm-A@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=047d7b8737aeea1fa2051469d0ef
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/nLBuxeEhi8BwjokjqutG0S6H84I>
Cc: "tls@ietf.org" <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: Thu, 23 Apr 2015 20:06:52 -0000

On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Thu, Apr 23, 2015 at 05:54:02AM -0400, Eric Rescorla wrote:
> > On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara <
> > ilari.liusvaara@elisanet.fi> wrote:
> >
> > > On Wed, Apr 22, 2015 at 05:30:42PM -0400, 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
> > > > >
> > > >
> > > > Basically, no.
> > > >
> > > > 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.
> > >
> > > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is
> > > seed,
> > > right?
> > >
> > > So inside that (or whatever the equivalent), serialize:
> > > - Label
> > > - Lengths, types and exportable flags of subkeys
> > > - Context
> > >
> > > ?
> > >
> > > Properly serializing that would avoid the well-known TLS 1.2 screwup in
> > > PRF defintion (which got copied to "dh based key exchange" draft).
> > >
> >
> > Can elaborate on this?
> >
> > The DH-based key exchange draft uses HKDF and uses separate
> > labels for each use of HKDF-Expand so that (for instance) exporters
> > and key generation have different labels.
>
> The label+seed thing.


My proposal for HKDF is to have null-terminated labels (in the same
way as for the signing contexts.




> > > Also, it occurs to me that if PRF has salt input (like HKDF), one
> should
> > > stick something non-secret but variable there (e.g. client random, or
> > > suitable handshake hash, or something).
> >
> >
> > Based on talking to Hugo, my understanding is that the best way
> > to do this is by incorporating the handshake hash at the HKDF-Expand
> > stage, as in:
> >
> > client_write_key = HKDF-Expand(Secret, "client write key" + session_hash,
> >                                  SecurityParameters.enc_key_length)
>
> Except that now nothing preturbs the secret extraction.


Can you explain what you mean by "perturbs"? If you include the session hash
it includes the randoms.


> If you're referring to how we combine (say) the static DH and the
> ephemeral
> > DH, what we had discussed was running K1 through HKDF-Extract to
> > generate PRK1 and then using PRK1 as the salt for HKDF-Extract on
> > PRK2. I.e.,
> >
> >    PRK1 = HKDF-Extract(0, K1)
> >    PRK2 = HKDF-Extract(0, K2)
>
> AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who
> described how to do 0RTT in simpler way.
>
> Also, maybe the only interesting application of FixedDH is deniable
> key exchange. Except that supporting that would cause major issues
> elsewhere (and "DH based key exchange" is not deniable).


It's not FixedDH, it's the servers semi-static DH and the client's
ephemeral.

-Ekr


> -Ilari
>