Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 17:37 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 E4D0C3A6B45 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:37:52 -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 at5MsgGV83XM for <tls@core3.amsl.com>; Thu, 5 Nov 2009 09:37:52 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DE9453A6B42 for <tls@ietf.org>; Thu, 5 Nov 2009 09:37:51 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5HcBhn022932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:38:11 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911051738.nA5HcA4Y000486@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Thu, 5 Nov 2009 18:38:10 +0100 (MET)
In-Reply-To: <4AF30A0E.5030409@extendedsubset.com> from "Marsh Ray" at Nov 5, 9 11:23:26 am
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] 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:37:53 -0000

Marsh Ray wrote:
> 
> Martin Rex wrote:
> >
> > 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.
> 
> I agree, the concept of "first handshake on the socket" is a bit
> nebulous from the perspective of the TLS spec.

For the secure renegotiation, the pointer exactly one TLS session
into the past seems perfectly sufficient to me.

Solving the nebulous concept of "first handshake on the socket"
is something that Larry wants a solution for, and which needs
a different approach.

The "secure naming" of a TLS connection has much more to do with
API semantics than with TLS wire-protocol and TLS session state.

TLS renegotiation does IMHO also interfere with the TLS PRF
(aka TLS-extractors), so that applications can not call it
at arbitrary points in their communication with a peer when
there might be a renegotiation between the point in time
when the client app calls in and when the server app calls it.


> 
> The approach our proposal took was to work off of the "most recent
> previous finished message" over the underlying transport.

The "secure random challenges" in a TLS handshake that protect
agains replay are the client.random and server.random.
Admittedly they're larger (2*32 octets, fixed size) than the
finished message (usually 12 octets, but depends on ciphersuite
according to rfc5246 7.4.9.)

The client.random and server.random of a connection are already
part of the official SecurityParameters (rfc5246 6.1.), but
the finished message is not.

-Martin