Re: [TLS] TLS renegotiation issue

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 05 November 2009 20:49 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 5D4153A68D6 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 12:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.716
X-Spam-Level:
X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 iE0JxI6TOyw3 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 12:49:26 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 6C4D43A68C8 for <tls@ietf.org>; Thu, 5 Nov 2009 12:49:26 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5KnmcY029577 for <tls@ietf.org>; Thu, 5 Nov 2009 20:49:48 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 nA5Knmft026469 for <tls@ietf.org>; Thu, 5 Nov 2009 13:49:48 -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 nA5KcHLL009374; Thu, 5 Nov 2009 14:38:17 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5KcHFL009373; Thu, 5 Nov 2009 14:38:17 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 5 Nov 2009 14:38:17 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20091105203817.GK1105@Sun.COM>
References: <20091105182625.GE1105@Sun.COM> <200911052021.nA5KLiAu010298@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200911052021.nA5KLiAu010298@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 20:49:27 -0000

On Thu, Nov 05, 2009 at 09:21:44PM +0100, Martin Rex wrote:
> 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?

Not really.

Eric's view seems to be that the TLS spec should say nothing about this.

I think it should, for the simple reason that it will help prevent this
sort of problem in the future.

> >                                 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.

You misunderstood the parenthetical.  The point was that one might think
that apps could get at the Finished messages without help, but in
reality they could only get at the protected Finished message, and only
if the TLS API was such that the apps could see the TLS record protocol
directly, and then only by implementing a heuristic -- all of which is
something we _don't_ want.  I wrote that parenthetical to preempt anyone
saying "why don't you just do [what the text in paren. talked about]?".

> 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.)

Wrong.  The GSS-API is NOT the only exception.  There's also SCTP, and
probably a number of otheres (heck, even IDNA has an abstract API).

Nico
--