Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 17:45 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 5889C3A696F for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level:
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 8uWojBkluH6F for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:45:25 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4BEF93A6869 for <tls@ietf.org>; Thu, 5 Nov 2009 09:45:25 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5Hjkvr000868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:45:46 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911051745.nA5Hjke7001138@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com (Nicolas Williams)
Date: Thu, 5 Nov 2009 18:45:46 +0100 (MET)
In-Reply-To: <20091105171308.GY1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 11:13:08 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: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] TLS renegotiation issue
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, 05 Nov 2009 17:45:26 -0000

Nicolas Williams wrote:
> 
> On Thu, Nov 05, 2009 at 06:11:41PM +0100, Martin Rex wrote:
> > One conceivable approach would be a TLS extension for secure renegotiation
> > with roughly the following semantics:
> > 
> > 
> >  - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL)
> >    the client that supports secure renegotiation should send the
> >    TLS extension in the client hello with an empty extension data
> >    to signal to the server that it support secure renegotation.
> > 
> >  - on TLS session renegotiations, the client should sent the TLS extension
> >    with the extension data containing the client.random and server.random
> >    from the existing session.
> 
> The MITM can make sure they match.

Not a problem.

If it does, that will become obvious in the verification of
the finished messages of the renegotiation handshake.

In addition to the Finished Message verification, such doctoring
will be detected in the ClientVerify verification by the server
when that is a signature over all previous handshake messages
(which is the default).


I'm usually prefer low-impact improvements, which can be added
to existing codebase with ease.  client.random | server.random
from the existing connection seems like a good candidate to me.


-Martin