Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 17:11 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 7CAEB3A6952 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:11:23 -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 hSCjdaKH-yyD for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:11:22 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D03053A694F for <tls@ietf.org>; Thu, 5 Nov 2009 09:11:21 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5HBg9d024137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:11:42 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911051711.nA5HBfOl028765@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Thu, 5 Nov 2009 18:11:41 +0100 (MET)
In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> from "Eric Rescorla" at Nov 4, 9 07:26:59 pm
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] 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:11:23 -0000

Eric Rescorla wrote:
> 
> Marsh Ray, the initial discoverer, has been working with a bunch of
> people in the security community to deal with this issue and develop
> a fix. Tomorrow AM I'll be posting an initial draft that describes
> the obvious fix, which is to cryptographically bind negotiations
> to any enclosing connection (if any). I won't be in Hiroshima but
> I expect the WG will want to discuss this topic.


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.

 - A server that receives a ClientHello without the TLS extension for
   secure renegotiation should NOT perform old-style renegotiation
   for that session (and get apps with flawed assumptions into trouble),
   i.e. NOT support delayed authentication for those TLS clients.

 - A server that receives a ClientHello on an initial TLS handshake
   with a TLS extension (empty data) for secure renegotiation may decide to
   delay client-cert authentication to a securely renegotiated session

 - A server that receives a ClientHello with a TLS extension for secure
   negotiation and a reference to a previous session MUST compare the
   client.random and server.random from the extension data to that of
   the current session (and abort if they do not match).  And the
   server should probably insist on doing a ChangeCipherSpec on both
   directions in the renegotiation handshake.


Since Larry is looking for a means to uniquely identify a single
TLS "connection" independent of whether its a single TLS handshake
or renegotiated, we should check whether we can carry-over some
information form the initial handshake on a connection along
with the client.random&server.random.  Technically there is no
limit on the number of renegotiations, so a simple pointer
only one TLS session into the past does not seem sufficient
for that purpose.



-Martin