Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Martin Rex <mrex@sap.com> Fri, 27 November 2009 14:01 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1303A6A48 for <tls@core3.amsl.com>; Fri, 27 Nov 2009 06:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.186
X-Spam-Level:
X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPi1viGdl1qy for <tls@core3.amsl.com>; Fri, 27 Nov 2009 06:01:31 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 48D663A67B6 for <tls@ietf.org>; Fri, 27 Nov 2009 06:01:31 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nARE1LP1011663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 15:01:21 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911271356.nARDuKVE026997@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Fri, 27 Nov 2009 14:56:20 +0100
In-Reply-To: <4B0F6B04.1090103@bolyard.me> from "Nelson B Bolyard" at Nov 26, 9 10:00:36 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Fri, 27 Nov 2009 14:01:32 -0000

Nelson B Bolyard wrote:
>
> For hardware security modules that implement SSL3, that change means
> replacing the HSM.  The only change you can make to the definitions of
> md5_hash and sha_hash that won't require the hardware to be replaced is
> to change the definition of "handshake_messages".  That means somehow
> making the additional data part of the data stream that gets input into
> that MD5 or SHA function before "Sender", perhaps as if it was a pseudo
> handshake message.


Which is one of the reasons why I'm favouring to expand the definition
of handshake messages for renegotiation and _NOT_ touch the PRF or
do other fancy stuff.  The one thing that SSLv3 and TLS have in
common is the concept of handshake message hash (a lot of other
stuff changed significantly).  The handshake message hash is
also the thing that goes into both, Finished and CertificateVerify.


-Martin