Re: [TLS] HSM-friendly Key Computation

Eric Rescorla <ekr@rtfm.com> Wed, 22 April 2015 17:38 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 1A3201B3901 for <tls@ietfa.amsl.com>; Wed, 22 Apr 2015 10:38:33 -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 lCvvLaAbveW8 for <tls@ietfa.amsl.com>; Wed, 22 Apr 2015 10:38:31 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 BF4FA1B3904 for <tls@ietf.org>; Wed, 22 Apr 2015 10:38:26 -0700 (PDT)
Received: by widdi4 with SMTP id di4so186876450wid.0 for <tls@ietf.org>; Wed, 22 Apr 2015 10:38:25 -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=pI3ms748oD6iislx/hXFETiLpVZLq+VHsmXttUx+/5s=; b=jg0WgRiruQpDKaJn7otKCOrt3MRmoMLk6LmpuULxum+zNM1UPNLRb9yyErXDCH+eAb b7zHXMzPtk1Ew2+cLd2u+N/g+O9bYZYjeUlp/Uu8yE0F4JSm97ATD1mkgwlshMRtUou/ hEtI+7rKIfeRvbYAOefpNhJwkgAV3+H3TqX0cgzPncqN0ydGT+ShABKn5ZDk/2obecXH uTMUVm65dqL8PO/9swp28QTWkMMeD8G0HFuifV/m3O7WexBEc5LnnUL9dB27JtSHlRKL jT5tW6Tuj2grbDyqtCb2HSZ+kirnQ+Lqy9Q6/W0hK6AZCmZ5OYv+F4GSRGsvjOQtbgUe c6yQ==
X-Gm-Message-State: ALoCoQnNhy6BDRSENsd9ocxenhnR93EZ5HToD5wmb+gLH5PFfd5xPuHj0KtRgrLyw8gWUddz0p/h
X-Received: by 10.180.74.208 with SMTP id w16mr7958014wiv.31.1429724305504; Wed, 22 Apr 2015 10:38:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.87 with HTTP; Wed, 22 Apr 2015 10:37:45 -0700 (PDT)
In-Reply-To: <20150422173526.GA14496@LK-Perkele-VII>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 22 Apr 2015 13:37:45 -0400
Message-ID: <CABcZeBPN33DM_C0sAmCTFCTdNrcQ7y7eEBcZgPe+2f1EaxtXzA@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=f46d043892175b5147051453a1ab
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/IrIAEAclfFQuhMG4laaNNfpAwxc>
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: Wed, 22 Apr 2015 17:38:33 -0000

If we're using HKDF-Extract, can we just key off different labels?

-Ekr


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
>