Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego

David-Sarah Hopwood <david-sarah@jacaranda.org> Tue, 10 November 2009 06:24 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 8643D3A693C for <tls@core3.amsl.com>; Mon, 9 Nov 2009 22:24:07 -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=[AWL=0.000, 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 lbwgN+GBAbyH for <tls@core3.amsl.com>; Mon, 9 Nov 2009 22:24:06 -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 1C95A3A6899 for <tls@ietf.org>; Mon, 9 Nov 2009 22:24:05 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 4so332443eyf.51 for <tls@ietf.org>; Mon, 09 Nov 2009 22:24:29 -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=5jLpQXjD+u2BqhgVdKA/j4IeAP7Gf52BV41vt6mEv6g=; b=jPSEGx403NSCW+qI/XQMtQ5lkuwhwDNjd7quLTgj4sdXmE8fM91ZehCnddnvwi7lBS wuLEgrUgMi297i+wG6mK98i+BCnMDY10QEG1WPzJUZjheb7jion101SMyCzqBCM8ijYC u2VlrduQ9hBnN4vtjWqq8XIyMJiyehG+sHE9M=
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=MnBGWPpNJNvnRzaWys45Hzu+M3S25F31nzvGvX/99TKrhlJ/ka+GBr5o4fWk+Uk+xd eQpLAbjv8E43frlnyPRGRl7sIWL/SA/SIQLJKS4552yCMUSbKchJTdZm/i7Bz8BVreRQ u8lms/bq8c4xTIu/JPToOjktcUz89C0+OIq0E=
Received: by 10.213.0.151 with SMTP id 23mr4443069ebb.43.1257834269264; Mon, 09 Nov 2009 22:24:29 -0800 (PST)
Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 24sm984531eyx.45.2009.11.09.22.24.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 22:24:28 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4AF9070E.4050305@jacaranda.org>
Date: Tue, 10 Nov 2009 06:24:14 +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: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org>
In-Reply-To: <4AF8FDBD.4080003@jacaranda.org>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enigF60FE6B14EA87530861FF446"
Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego
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, 10 Nov 2009 06:24:07 -0000

David-Sarah Hopwood wrote:
> Michael D'Errico wrote:
>>> Suppose that the client sent an SSLv3 ClientHello
>>> with client_version = 3.1 (or higher). Assuming the server supports TLS,
>>> then TLS will be negotiated. So when the client sends the renegotiation,
>>> it knows that it is safe to send extensions. The attack is prevented as
>>> long as the renegotiating handshake uses the extension; it is not
>>> necessary for the initial handshake to have used it.
>> The problem is that your initial handshake *is* the renegotiation!
>> (from the server's point of view)
> 
> I may well be confused, but: a handshake is a renegotiation if-and-only-if
> it is encrypted. Initial handshakes are in the clear. So there is no
> ambiguity, from either party's point of view, about whether a handshake
> is a renegotiation.

Actually this is not quite right, although not in a way that affects my
main point.

A handshake is a renegotiation from the server's point of view
if-and-only-if a ciphersuite other than TLS_NULL_WITH_NULL_NULL is
in effect. It is possible that an initial handshake by a client that
was sent in the clear, could be encrypted by an attacker and appear to
the server as a renegotiation. In that case, the server can reject the
renegotiation if the ClientHello doesn't contain a correct (and non-empty)
Renegotiation_Info.

It is also possible that, if a client that does not support the extension
requests a renegotiation on a session with the attacker, then the attacker
can decrypt it and present it to the server as an initial handshake.
But this only applies to clients that do not support the extension at all.
If a client does support it and sends it only when renegotiating, then
this variant of the attack is still prevented.

So, I was right in my original statement that "the attack is prevented
as long as the renegotiating handshake uses the extension." Note that
both clients and servers must avoid renegotiating without using the
extension; it isn't sufficient for only servers to avoid doing so.
As long as that is the case, for a client does support the extension,
failing to send the zero-length Renegotiation_Info in an initial handshake
does not enable an attack.

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