Re: [TLS] TLS renegotiation issue

Martin Rex <> Thu, 05 November 2009 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 007A93A67AF for <>; Thu, 5 Nov 2009 12:21:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.749
X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kQjgM+rwPJfg for <>; Thu, 5 Nov 2009 12:21:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D10C13A6782 for <>; Thu, 5 Nov 2009 12:21:23 -0800 (PST)
Received: from by (26) with ESMTP id nA5KLjtv017450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 21:21:45 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Nicolas Williams)
Date: Thu, 5 Nov 2009 21:21:44 +0100 (MET)
In-Reply-To: <20091105182625.GE1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 12:26:26 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
Subject: Re: [TLS] TLS renegotiation issue
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2009 20:21:25 -0000

Nicolas Williams wrote:
> On Thu, Nov 05, 2009 at 07:16:02PM +0100, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > You can't use the client.random and server.random as channel bindings.
> > 
> > I'm trying to use terminology that is already in the TLS specs.
> > The generic term "channel bindings" is a little bit to fuzzy for
> > my taste, and the original use of channel bindings in GSS-API
> > is not cryptographically secure.
> I understand.  The spec will just have to be updated to say that the
> finished messages (or at least the client one) are to be exported to
> applications.

Huh -- wrong topic?

Eric's proposal to make renegotiation secure does not need any
API-level changes, everything is completely internal to the
TLS protocol engine.

What you're looking for might be necessary for application-level
channel bindings, but that is a different topic.

I don't mind discussing this, but I would appreciate if you identify
the topic/solution that you're discussing.  ;-)

>                                 I perfectly understand, and _share_, the
> desire to use existing interfaces where possible.  In this case there is
> no such interface (in some TLS APIs apps could parse the TLS record
> layer and heuristically find the record that contains the protected
> client Finished message, but that's... not really an interface, not what
> we wnat, and not reliably available everywhere).

On the network, the finished messages are protected under the negotiated
ciphersuite.  Eric's proposal used the verify_data in its decrypted
form, and I thought you were asking for these as well.

> We've looked at this problem many times before, and this is always the
> conclusion that we've come to.  I really wish that TLS 1.2 had made the
> client Finished messages part of the exported security parameters (I
> really wish I'd thought to make sure that 1.2 did that).  But then,
> making the 1.2 spec say this is not enough: installed base inertia is
> what makes it hard to ensure that Finished messages are exported.

Exported security parameters?

Your desire to get your hands on the finished message from the
App layer for channel binding purposes is an API issue.

The TLS-specs describe only bits-on-the-wire, protocol semantics
and TLS session state management.  The TLS specs are entirely
silent on API issues.  (The IETF does not do APIs, and GSS-API
is an exception.)