IETF Logo Mail Archive

Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 20 April 2015 06:42 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 A15551ACE74 for <tls@ietfa.amsl.com>; Sun, 19 Apr 2015 23:42:48 -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 OPxZnRT4cU1y for <tls@ietfa.amsl.com>; Sun, 19 Apr 2015 23:42:46 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3DF1ACE72 for <tls@ietf.org>; Sun, 19 Apr 2015 23:42:46 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 0DBF581867; Mon, 20 Apr 2015 09:42:43 +0300 (EEST)
Date: Mon, 20 Apr 2015 09:42:43 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Michael StJohns <msj@nthpermutation.com>
Message-ID: <20150420064243.GA7322@LK-Perkele-VII>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5533F8D6.9070500@nthpermutation.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/nXDHwFDLlAdR1KPBpJ8v0v3LvxI>
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: Mon, 20 Apr 2015 06:42:48 -0000

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.

Also, true MAC functions just aren't enough for some places (such as
deriving the various master secrets or unique value).



-Ilari

v2.8.7 | Report a Bug | By Email