Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 20 April 2015 16:38 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 132E91A1A39 for <tls@ietfa.amsl.com>; Mon, 20 Apr 2015 09:38:00 -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 kMMEf_HyMhAG for <tls@ietfa.amsl.com>; Mon, 20 Apr 2015 09:37:57 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83101A1A33 for <tls@ietf.org>; Mon, 20 Apr 2015 09:37:57 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 5020A90040; Mon, 20 Apr 2015 19:37:55 +0300 (EEST)
Date: Mon, 20 Apr 2015 19:37:55 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: "StJohns, Michael" <msj@nthpermutation.com>
Message-ID: <20150420163755.GA15511@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CANeU+ZAL6oT6tP7OcL_8j6kp4oZB9V89R-0PrCdv-N27qVb0HQ@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/o6i_S3buFNQ-afWH-BmMS-AObqo>
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: Mon, 20 Apr 2015 16:38:00 -0000

On Mon, Apr 20, 2015 at 12:09:56PM -0400, StJohns, Michael wrote:
> On Monday, April 20, 2015, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> wrote:
> 
> > On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote:
> > >
> > > What I would love to see for TLS1.3 is NO TLS specific mechanisms being
> > > added to PKCS11.    That if we still sign the finished message, we use a
> > > true MAC function.  That if we derive keys, we use a bog standard KDF.
> > That
> > > we stomp on every TLS specific twist unless there is a specific security
> > > need to keep TLS secure.
> >
> > Not possible. There are features (e.g. extractor and resumption/unique
> > interaction) that can't be feasibly removed (or even deprecated) and which
> > need PRF'ing secret keys into public data.
> 
> I'm not quite sure how you've come to this conclusion.  The underlying
> function for a KDF is generally a MAC function which by definition produces
> public data.  It's only when bound into a KDF that it by definition
> produces secret data.  The main problem we've encountered is that we use
> the same key to produce public (IV) data and private key material.   Fixing
> this is more an issue of how to cryptographically isolate products of the
> diverse operations in a way that enhances security.

Maybe I used bad terminology, but...

There are other places in TLS that fundamentally need to (indirectly) derive
public data out of secret key material.

E.g. extractor and unique/resumption-interaction. There might be others as
well.


-Ilari