Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal

Nicolas Williams <Nicolas.Williams@sun.com> Sat, 14 November 2009 08:52 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 17E4A3A682A for <tls@core3.amsl.com>; Sat, 14 Nov 2009 00:52:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.025, 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 nauoK83U0kwj for <tls@core3.amsl.com>; Sat, 14 Nov 2009 00:52:20 -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 293713A6820 for <tls@ietf.org>; Sat, 14 Nov 2009 00:52:20 -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 nAE8qo34024048 for <tls@ietf.org>; Sat, 14 Nov 2009 08:52:50 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 nAE8qo7I006986 for <tls@ietf.org>; Sat, 14 Nov 2009 01:52:50 -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 nAE8fF9V019958; Sat, 14 Nov 2009 02:41:15 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAE8fF5M019957; Sat, 14 Nov 2009 02:41:15 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Sat, 14 Nov 2009 02:41:15 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: David-Sarah Hopwood <david-sarah@jacaranda.org>
Message-ID: <20091114084115.GF1105@Sun.COM>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4AFE4091.10005@jacaranda.org>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal
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: Sat, 14 Nov 2009 08:52:21 -0000

On Sat, Nov 14, 2009 at 05:30:57AM +0000, David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
> > The problem is that this unnecessarily breaks cases in which the
> > possibility of attack couldn't have been prevented (because only
> > one of the client and server supports the extension), and in which
> > there may actually be no attack.
> 
> No, on further consideration this argument is wrong. Since adding the
> verify_data into the Finished hashes would only happen for renegotiations,
> it cannot cause any interoperability failures on an initial handshake.
> It would cause a handshake failure on a renegotiation, if only the client
> or only the server has been patched.

Right.

> Note that a handshake failure in that case doesn't necessarily result in
> an interoperability failure. That's because many clients will fall back
> to reconnecting on a new session, if a renegotiation fails. In fact,
> implementors of web browser clients essentially have no choice but to
> do this if they want to interoperate with many web servers (the situation
> might be different for non-HTTP protocols) [*].

Right.

> On the other hand, consider the case of a patched client performing an
> initial handshake with an unpatched server. If an extension is not used,
> then there is no way for the client to tell that the server is unpatched,
> and the connection might succeed even though an attack is taking place.
> Using the extension would give patched clients the option of refusing to
> connect to unpatched servers.

Irrelevant: nothing that goes over the first connection should be at
risk or sensitive, provided that the client did authenticate the server
OR, if an anon-anon cipher suite was used, (that the client refrained
from sending confidential data AND the client did not take destructive
action based on data from the server).

It's OK for the client to learn that the server is unpatched when it
tries to re-negotiate.

> The converse situation, where a patched server does not know whether it
> is talking to a patched or unpatched client, is probably less significant:
> an attack can only succeed in that case if the client does not check the
> server's certificate, in which case a MITM attack is possible anyway.

Right.

> Important point: TLS- or extension-intolerant servers are all unpatched.

Yes.  But I get the feeling that some folks think it will be easier to
patch them than to upgrade them.  My proposal is particularly useful
then, since it can be applied even to SSLv3.

NOTE: I'm not trying to force a design change at this late stage.  I had
      a caveat at the top of my proposal that it should only be
      considered if the use of extensions turned out to be problematic.

Nico
--