Re: [TLS] TLS renegotiation issue

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 05 November 2009 18:37 UTC

Return-Path: <Nicolas.Williams@sun.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 084983A6B40 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level:
X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 n7A9X4ysV4UM for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:37:34 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 2FB053A68E0 for <tls@ietf.org>; Thu, 5 Nov 2009 10:37:34 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5Ibuxr027787 for <tls@ietf.org>; Thu, 5 Nov 2009 18:37:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA5Ibu2P065507 for <tls@ietf.org>; Thu, 5 Nov 2009 11:37:56 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA5IQQKx009291; Thu, 5 Nov 2009 12:26:26 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5IQQ9B009290; Thu, 5 Nov 2009 12:26:26 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 5 Nov 2009 12:26:26 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20091105182625.GE1105@Sun.COM>
References: <20091105175044.GG5124@Sun.COM> <200911051816.nA5IG292002997@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200911051816.nA5IG292002997@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
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
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 18:37:35 -0000

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.

TLS implementors, know this: you must update your implementations to
export to applications, at least the client Finished message for at
least any and all "outer-most" TLS handshakes (that is, handshakes not
protected by another TLS connection's record layer).

This is just a matter of interfaces for all software implementations.
For hardware implementations it's going to be tougher -- particularly
tough for concentrator implementations.  (Provided that a concentrator
terminates both, the outer and inner TLS connections, then all other
uses of TLS channel binding can use the tls-server-end-point channel
binding type.  But really, you'll want to export the tls-unique channel
bindings.)

> > But the client's Finished message from the outer TLS connection works.
> 
> OK.
> 
> You win.  ;-)

Hey, it's not about winning!  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).

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.

Nico
--