Re: [TLS] TLS renegotiation issue

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 05 November 2009 20:41 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 CE3273A6889 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 12:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.015
X-Spam-Level:
X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 U4h3RjPtkYZ1 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 12:41:56 -0800 (PST)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id E348E3A67AD for <tls@ietf.org>; Thu, 5 Nov 2009 12:41:56 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5KgGia023285 for <tls@ietf.org>; Thu, 5 Nov 2009 20:42:16 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 nA5KgGGf021172 for <tls@ietf.org>; Thu, 5 Nov 2009 13:42:16 -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 nA5KUj2N009361; Thu, 5 Nov 2009 14:30:45 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5KUjQL009360; Thu, 5 Nov 2009 14:30:45 -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:30:45 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20091105203044.GI1105@Sun.COM>
References: <20091105184615.GG1105@Sun.COM> <200911051929.nA5JTSaR007035@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200911051929.nA5JTSaR007035@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:41:57 -0000

On Thu, Nov 05, 2009 at 08:29:28PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > Initial comments based on a brief skim:
> > 
> >  - Please add a normative reference to RFC5056.
> 
> I admit to not know what that exactly means, but it sounds wrong.
> 
> It is perfectly possible to write this document in a fashion that
> an implementor does NOT NEED to read rfc5056, and therefore I
> would strongly prefer to keep it that way.

Referencing RFC5056 wouldn't so much be to provide guidance to
implementors as to say "this document conforms to RFC5056".

> >  - There's no real need for the ServerHello to include both of the
> >    Finished messages from the outer TLS connection.  (I think there's no
> >    real need for the ServerHello to include either of them, actually,
> >    but I've not thought enough about that.)  But it's OK as is, of
> >    course.
> 
> The Server should send back something different than on initial
> connect in order to indicate to the client that it is convinced
> this is a renegotiation rather than an initial handshake.

Indeed, it must send something.  Even one bit will do -- that was my
point.

> Sending back the verify_data from Server finished seems fair to me.

I agree -- that allows the client to verify that the server did
something more than agree.  There's no point in the server sending back
the client's Finished message though -- that adds no value and wastes
space on the wire (very little, granted).

> >    (In practice there's probably never more than one outer and one inner
> >    handshake, right?)
> 
> Technically, there can NEVER be more than two, as required by the TLS
> spec (there is only one current and one pending) so technically, the
> existing proposal is referencing the "outer-most" TLS session.

Interesting.

> >  - There is a way for clients to protect themselves even when servers
> >    don't implement this extension:
> 
> I would hope there is a way, but I have not seen one so far!
> 
> There are actually two different scenarios:
> the one I suggested where both sides, client and server perform
> a renegotiation, and the one described by Marsh, where a clients
> initial TLS handshake is proxied into a renegotiation for the
> server.

Ah.  I was considering only one of those attacks.  You're correct, there
is no workaround short of fixing the protocol.

> >  - Might as well update RFC5246 to indicate that the Finished messages
> >    for any connection MUST be exported to applications.  Better get this
> >    done now.
> 
> I haven't sufficiently thought about this to like it.
> 
> Adding the finished messages to the renegotiation handshake
> is fine, because they have originally exchanged under the protection
> of the currently active ciphersuite, so this should have zero impact.

For an implementation like Microsoft's SSPI-based implementation TLS
that might not be true, since there each TLS connection is represented
by a separate "security context" -- for such an implementation the fix
requires that the application help the implementation link those
security contexts.

> You're asking to make something available that has not been previously
> available to the application.  This might be harmless, but I don't know.

How could it not be harmless?  What damage could ensue from making the
Finished messages of a TLS connection available to the application?
Remember: there are cipher suites that provide only integrity
protection, therefore Finished messages must not leak any information
about the master secret (and indeed, they do not, module the
cryptographic strength of the relevant algorithms used in the Finished
message construction).

Nico
--