IETF Logo Mail Archive

Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

"Rob P Williams" <rwilliams@certicom.com> Wed, 11 November 2009 20:21 UTC

Return-Path: <rwilliams@certicom.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 456573A69F6 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 12:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level:
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 fusruPHaEus9 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 12:21:17 -0800 (PST)
Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 8D4543A685E for <tls@ietf.org>; Wed, 11 Nov 2009 12:21:15 -0800 (PST)
X-AuditID: 0a401fcb-b7bb7ae000005c61-50-4afb1cd76209
Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id AD.26.23649.7DC1BFA4; Wed, 11 Nov 2009 15:21:43 -0500 (EST)
Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:21:42 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
Date: Wed, 11 Nov 2009 15:21:42 -0500
Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4023805E5@XCH57YKF.rim.net>
In-Reply-To: <4AFB154A.9030106@extendedsubset.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] TLSrenego - possibilities, suggestion for SSLv3
Thread-Index: AcpjCCHeQvhskyqzS96B/nl5lhhdkQAABhdA
References: <4AFA36A8.9010805@extendedsubset.com> from "Marsh Ray" at Nov 10, 9 09:59:36 pm, <200911111916.nABJGtVm015003@fs4113.wdf.sap.corp><CE2A65CAAFE55048BA6682475F9A7DBF5EA6E601BC@ACLMAIL01.corp.audiocodes.com> <4AFB154A.9030106@extendedsubset.com>
From: Rob P Williams <rwilliams@certicom.com>
To: tls@ietf.org
X-OriginalArrivalTime: 11 Nov 2009 20:21:42.0562 (UTC) FILETIME=[95181020:01CA630C]
X-Brightmail-Tracker: AAAAAQAAAZE=
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/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: Wed, 11 Nov 2009 20:21:18 -0000

Hi,

I have a different suggestion for keeping SSLv3 safe.

The problem for SSLv3 and TLS1~1.2 was created here:

5.6.9 Finished

handshake_messages         All of the data from all handshake messages
                           up to but not including this message.  This
                           is only data visible at the handshake layer
                           and does not include record layer headers.

If ALL handshake messages were used - this problem would not exist.
Implementations have treated 'all' as 'from the current handshake'.
(TLS1.0 cemented this problem).

By changing the way the Finished message is calculated - you can make
SSLv3 safer.

Approach:

    For initial handshakes - keep the calculation the same.

    For subsequent handshakes - 
        append extra information to 'handshake_messages' before being
hashed.
        This could be as simple as a counter. 
        This could be the finished data from the previous handshake.

	I've attempted to draw a table of what would happen when
renegotiating;

	OC = old client
	NC = new client
	OS = old server
	NS = new server


            OS   | NS
           ------+-----
      OC  |  .   | fail
      NC  | fail | good


OC-NS failure - is useful - 
    it shows the attack being mitigated.
NC-OS failure - is ALSO useful.
    By attempting to renegotiate - you can verify if you are talking to
an OS or NS.


--
rob | Software Developer
Certicom Corp. | A susbidiary of Research In Motion Limited

main | +1 905-507-4220
direct | +1 905-501-3887

rwilliams@certicom.com
www.certicom.com




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

v2.23.0 | Report a Bug | By Email