Re: [TLS] TLS and hardware security modules - some issues related to PKCS11

mrex@sap.com (Martin Rex) Tue, 17 September 2013 12:50 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167F211E8440 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 05:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV3z95YhY3O8 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 05:50:02 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2895911E8429 for <tls@ietf.org>; Tue, 17 Sep 2013 05:49:49 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8HCnmAF012464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 14:49:48 +0200 (MEST)
In-Reply-To: <52379643.7070705@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
Date: Tue, 17 Sep 2013 14:49:48 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 17 Sep 2013 12:50:07 -0000

I fail to understand what you're trying to protect.

The master secret of a session is never a secret that is hidding
within the hardware module, instead, it is something known to the
calling TLS protocol stack and part of the TLS session cache.

For vanilla RSA cipher suites, it is deterministically derived
from randomness generated by the client and conveyed under
RSA encryption, deterministically combined with data known
in plain to the TLS protocol stack.

-Martin