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

David-Sarah Hopwood <david-sarah@jacaranda.org> Sat, 14 November 2009 22:01 UTC

Return-Path: <djhopwood@googlemail.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 ADCB73A679C for <tls@core3.amsl.com>; Sat, 14 Nov 2009 14:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ogs5kNOjI6LT for <tls@core3.amsl.com>; Sat, 14 Nov 2009 14:01:52 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 4DE4F3A6359 for <tls@ietf.org>; Sat, 14 Nov 2009 14:01:52 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 9so1426201eyd.51 for <tls@ietf.org>; Sat, 14 Nov 2009 14:02:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=U1ytpuN8eIaIOzlF7uEEHQj43u3jCNELRNAUO842mHs=; b=SS5YPdVWFLM2hUXyctGw1AB9JeN0dm5cFN9/Ngh5+DtVdVJpymemMrZi60QZJ5+PFD FTCc7tgmulnvvYaW/qW6nigcpJXRc0mTfWjJjBJxic2dqLwWwROwBnaqnBqEqJBFUIgh FXVj+UZW0q47IG9yRlnnuuaOAkMGKwTITUYi0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=Bbfk8mB72EZbgqQwKCzCVBKQQgA65UO8UYiTFn4DJB+7DM5itieVxhEN0wb7RTXtAY aKtJuBsT3Ehk47caU4MO/0HLumwKSxkLm9Ix2tQBxZJb9AVsEtaPEofMYnO5G1u+F33T QvMG2mjTuPFEQ2WAMskTTPyZTG2OVGJ6H0p9I=
Received: by 10.213.24.9 with SMTP id t9mr2475329ebb.4.1258236135834; Sat, 14 Nov 2009 14:02:15 -0800 (PST)
Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 7sm2827621eyg.17.2009.11.14.14.02.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 14:02:15 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4AFF28DE.4080709@jacaranda.org>
Date: Sat, 14 Nov 2009 22:02:06 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <20091113005419.GQ1105@Sun.COM> <4AFE1408.9040706@jacaranda.org> <4AFE4091.10005@jacaranda.org> <20091114084115.GF1105@Sun.COM>
In-Reply-To: <20091114084115.GF1105@Sun.COM>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1F70FD484894F8621322C2E8"
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 22:01:53 -0000

Nicolas Williams wrote:
> 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. [...]
> 
> 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).

No, that's not correct. The client's session may have been prefixed by
data chosen by the attacker. Therefore everything sent in that session is
at risk.

This depends to some extent on the application protocol, but I would
expect almost all protocols to be potentially vulnerable -- although not
all implementations.

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

An attack can occur even against connections of a client that *never*
renegotiates, if it is connecting to an unpatched server.

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

The easiest patch is to just disable renegotiation. If you're going to
do anything more complicated than that, I don't think it makes any sense
at all to leave the server in a state where it is still TLS- or
extension-intolerant.

Note that we don't need such servers to support TLS; only to tolerate a
TLS ClientHello with extensions, and perform version negotiation correctly
for whatever version(s) they do support.

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

Yes, that also applies to my suggestion of adding in the Finished hashes
unconditionally for renegotiations, and treating the extension as
advisory. It would be helpful to know to what extent implementors of
commonly used clients actually still think that it is problematic to use
extensions on an initial handshake. (For HTTPS, it would be particularly
interesting to know what Internet Explorer's behaviour would be once it is
patched.)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com