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

David-Sarah Hopwood <david-sarah@jacaranda.org> Tue, 10 November 2009 04:44 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 3BEB23A69CF for <tls@core3.amsl.com>; Mon, 9 Nov 2009 20:44:47 -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 PmeO1yRzz73g for <tls@core3.amsl.com>; Mon, 9 Nov 2009 20:44:46 -0800 (PST)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id A4B143A696F for <tls@ietf.org>; Mon, 9 Nov 2009 20:44:41 -0800 (PST)
Received: by ewy3 with SMTP id 3so3886848ewy.37 for <tls@ietf.org>; Mon, 09 Nov 2009 20:45:05 -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=ZEWF9hqtuC3yj3dhY0iKGuXUmjcwoz0JVo3SbIiDF9c=; b=a3JZskwqkQNl+1WzH7Sg8qudQVByKSvwUA4jUo6vLwGUT2Oz0fZtlqDkQrAjpHHqHo VCnn6q22v5VFQM0wC+unuN+NIE8PLAp7l9WCMHD5dmuQs5yDCHz2g1v8zBeVfzuMsWAy XdAstpYvE/do+tFZwbOsU+9Qn3A/NNOVq7SEY=
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=gdFE6W2SiTmL4IGmToL26PMM7eMAQsVql5F00ueRgjY66HgBpIKw99d/UYln2XhYNB t0flgilNhaYRUuCmX1dgqFMViwd8c1h8P16zR3u/r6e4ONwQwHkGi23runYcczFJm6jb XeflFpPHJ2cCR3z31BAJW1MNP1gAbOyc6oOm4=
Received: by 10.213.25.79 with SMTP id y15mr9954102ebb.78.1257828305341; Mon, 09 Nov 2009 20:45:05 -0800 (PST)
Received: from ?192.168.0.2? (5e057cdf.bb.sky.com [94.5.124.223]) by mx.google.com with ESMTPS id 28sm842278eyg.46.2009.11.09.20.45.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 20:45:04 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4AF8EF8F.3090100@jacaranda.org>
Date: Tue, 10 Nov 2009 04:43:59 +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>
In-Reply-To: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enigDD56E015EA3A4EBC61CFE247"
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 04:44:47 -0000

Martin Rex wrote:
> Maybe a patched Server (one with support for secure renegotiation)
> should ALWAYS assert this extension in a renegotiation TLS handshake
> _with_ the verify_data of both server.finished and client.finished
> in the ServerHello -- including when the client didn't send the
> extension (maybe because the client didn't dare confusing an SSLv3 server).
> 
> If we recommend the Server to no longer perform insecure renegotiation,
> we could instead recommend that the server unconditionally asserts the
> ServerHello extension for the renegotiation handshake.

That's not necessary. 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.

However, the draft is not clear enough on that last point. It should
clarify that, while including a zero-length Renegotiation_Info implies
that the extension is supported (by either the client or server), the
converse is not true: lack of a Renegotiation_Info extension on the first
handshake does not imply that the extension isn't supported.

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