Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 22 April 2015 17:35 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 DA4F51B38EA for <tls@ietfa.amsl.com>; Wed, 22 Apr 2015 10:35:32 -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 wMFHC0vjHXw0 for <tls@ietfa.amsl.com>; Wed, 22 Apr 2015 10:35:31 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598A81B38EF for <tls@ietf.org>; Wed, 22 Apr 2015 10:35:29 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id BE9B1699A6; Wed, 22 Apr 2015 20:35:26 +0300 (EEST)
Date: Wed, 22 Apr 2015 20:35:26 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Robert Relyea <rrelyea@redhat.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5537D43A.9080802@REDHAT.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/TJv46FHwmSq2-4DHJte_c6kLwqA>
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: Wed, 22 Apr 2015 17:35:33 -0000

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