Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

Yoav Nir <ynir@checkpoint.com> Tue, 15 December 2009 08:21 UTC

Return-Path: <ynir@checkpoint.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 DF0CA3A697D for <tls@core3.amsl.com>; Tue, 15 Dec 2009 00:21:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.066
X-Spam-Level:
X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, SARE_UNSUB22=0.948]
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 a30zAdSJAFHD for <tls@core3.amsl.com>; Tue, 15 Dec 2009 00:21:40 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6ECD83A67BD for <tls@ietf.org>; Tue, 15 Dec 2009 00:21:39 -0800 (PST)
X-CheckPoint: {4B27463B-10001-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7C8BE29C009; Tue, 15 Dec 2009 10:21:24 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6781129C002; Tue, 15 Dec 2009 10:21:24 +0200 (IST)
X-CheckPoint: {4B27463A-10002-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBF8LOT7026344; Tue, 15 Dec 2009 10:21:24 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 15 Dec 2009 10:21:34 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: David-Sarah Hopwood <david-sarah@jacaranda.org>
Date: Tue, 15 Dec 2009 10:21:20 +0200
Thread-Topic: [TLS] Closing some open comments on draft-ietf-tls-renegotiation
Thread-Index: Acp9X5ymI0N+5Xo+SrSDShpZg3y9Vg==
Message-ID: <ABE8B0A5-EDBE-48B4-BAD4-577CA0730DC8@checkpoint.com>
References: <C74C296E.63A%gajek@post.tau.ac.il> <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> <4B26F86D.4020601@jacaranda.org>
In-Reply-To: <4B26F86D.4020601@jacaranda.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation
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: Tue, 15 Dec 2009 08:21:44 -0000

On Dec 15, 2009, at 4:46 AM, David-Sarah Hopwood wrote:

> Yoav Nir wrote:
>> It would be easy to require this, but it's not compliant with the current
>> spec. The current spec says that the finished value depends on all the
>> bytes starting with the first byte of the ClientHello.
>> 
>> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but
>> adding the previous finished message is a change to the spec, one that
>> requires some sort of signaling, either with a fake cipher suite or with
>> an extension.
> 
> No, this is a misunderstanding; changing how the Finished message is
> computed *for renegotiations* does not necessarily require signalling.
> 
> Changing the way that the Finished message is computed *only* for
> renegotiations, would affect interoperability only when there is a
> renegotiation where one peer is unpatched and the other is patched.
> Under that condition, being interoperable would allow an attack.

That is just wrong. An RFC compliant client negotiating with an RFC compliant server must not get a wrong Finished message. That's changing the protocol, and it requires signaling either by a new version number or something else. You can't now change the base 1.2.

> (Some have argued for allowing patched clients and servers to favour
> interoperability over security in this case. I don't agree that that is
> desirable.)

That's not for you to decide. It's for the client and server vendors, and they may or may not pass this decision to their customers.

> Furthermore, changing the Finished message only for renegotiations is
> sufficient to prevent attacks provided that the renegotiating peer
> has been updated.

It's also sufficient to break some things.

> By itself, however, that would not allow clients to detect non-patched
> servers. It is likely, and desirable, that some clients will adopt a
> "strict" policy in which they fail an *initial* connection to a non-patched
> server. Technically, only the server->client signal is directly necessary
> for this. The client->server signal is needed to allow the server->client
> signal to be sent without the possibility of breaking unpatched clients.
> 
> (The client->server signal also allows servers to reject initial
> connections from unpatched clients. However, it's unlikely in practice
> that servers will follow that policy, and it's not necessary to prevent
> the most serious variant of the attack.)
> 
> -- 
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>