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

Martin Rex <mrex@sap.com> Thu, 26 November 2009 05:50 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 DA4703A69DE for <tls@core3.amsl.com>; Wed, 25 Nov 2009 21:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.181
X-Spam-Level:
X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 gflkg9yvzBpR for <tls@core3.amsl.com>; Wed, 25 Nov 2009 21:50:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D92D93A6961 for <tls@ietf.org>; Wed, 25 Nov 2009 21:50:24 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQ5oINb027784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 06:50:18 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911260550.nAQ5oID8027283@fs4113.wdf.sap.corp>
To: david-sarah@jacaranda.org
Date: Thu, 26 Nov 2009 06:50:18 +0100
In-Reply-To: <4B0E0EF4.7000102@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:15:32 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
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: Thu, 26 Nov 2009 05:50:25 -0000

David-Sarah Hopwood wrote:
> 
> The old verify_data should not just be appended to the handshake_messages
> without any further encoding, though, because it might match the bytes
> of some valid handshake message. In that case, there is the possibility
> that a MITM might insert the old verify_data into the stream sent to
> one peer, as though it were a handshake message. If that peer is using
> the unmodified Finished computation (either because it is unpatched or
> it is doing an initial handshake), then it may end up computing the same
> Finished hash as the other peer that is using the modified computation.
> 
> I haven't gone through the details of this attack thoroughly enough
> to be sure it will work, but it is too near working for comfort.

There are no handshake messages after finished.

You forgot the signaling in the ServerHello and ClientHello
that is also covered by the handshake message hash.

the verify_data should be added directly following ServerHello.

-Martin