IETF Logo Mail Archive

Re: [TLS] HSM-friendly Key Computation

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Sun, 19 April 2015 08:27 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 7DF481A6F2A for <tls@ietfa.amsl.com>; Sun, 19 Apr 2015 01:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 49fR66qRwWAE for <tls@ietfa.amsl.com>; Sun, 19 Apr 2015 01:27:17 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21541B2A81 for <tls@ietf.org>; Sun, 19 Apr 2015 01:27:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,602,1422918000"; d="scan'208";a="112027089"
Received: from ra178-1-88-163-20-214.fbx.proxad.net (HELO [192.168.0.24]) ([88.163.20.214]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2015 10:27:14 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz>
Date: Sun, 19 Apr 2015 10:27:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CEE16DF6-6D45-4B1C-ABA0-C7A659E728E4@inria.fr>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AqjCVUd2NynsA4oiRYr-JExg4jc>
Cc: ML IETF TLS <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: Sun, 19 Apr 2015 08:27:19 -0000

Hi,

> On 19 Apr 2015, at 06:22, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
> Russ Housley <housley@vigilsec.com> writes:
> 
>> If one wants to implement the cryptographic functions in a Hardware Security
>> Module (HSM), this structure is far from ideal.
> 
> Weelll... it's far from ideal if you want to use traditional/historic PKCS #11
> mechanisms, but since a new PRF will need updated HSM support anyway it
> shouldn’t be any problem to accommodate it
…
>   It's an issue for the HSM vendors to adapt, not the TLS spec
> to adapt.

I agree with Peter. Anyway, everyone will have to spend some time and money to update their HSMs at some point.
That said, if we can sync all major changes in a batch, we should try to do so.

But in general it should not be our concern, else we can never improve the crypto and the protocol.
Cheers,

B.

v2.23.0 | Report a Bug | By Email