Re: [TLS] Comments on draft-rescorla-tls-renegotiate

David-Sarah Hopwood <david-sarah@jacaranda.org> Sat, 14 November 2009 02:20 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 CB1AD3A6926 for <tls@core3.amsl.com>; Fri, 13 Nov 2009 18:20:44 -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 Rh85splCOGCu for <tls@core3.amsl.com>; Fri, 13 Nov 2009 18:20:44 -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 BDB653A6808 for <tls@ietf.org>; Fri, 13 Nov 2009 18:20:43 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 9so1144361eyd.51 for <tls@ietf.org>; Fri, 13 Nov 2009 18:21:10 -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=R0VA7WX+R7h/jeodxPYWeL2izHBSDql4dC17daiuSn0=; b=jjIi0rfQC9PtyL8yUY62CFZWBZwZvbXClSp7byDU4ZclpNYrnsms0ArWz1q5KamGnL 6GlepF71rbAW/YLdnxHpyBctenCneLkM44He90kGDgdbFBto+zxkGOQtxiIkEMk2C7IY 4Y7axjul10M+uGLJqb99EbjlH8ai8TVyy1F6c=
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=KN8/A+4xzFwGIOpJGPd3HdCxQR0cPqiXOvVwlWYLfKvGy7NgmqVN9najxpzD6mjFXm E5kmLtv+3D8wXzmE2NXCGylcT/kOJVn3o3RqkmZvYfkb/I8HnpjIk2mXMtO7FbdGyliH aAtOL7w0eLek/1azlxt/jzTe/ZbKoeQvHh6LI=
Received: by 10.213.100.65 with SMTP id x1mr3376130ebn.67.1258165270054; Fri, 13 Nov 2009 18:21:10 -0800 (PST)
Received: from ?192.168.0.2? (5e06f2bf.bb.sky.com [94.6.242.191]) by mx.google.com with ESMTPS id 7sm1436813eyg.17.2009.11.13.18.21.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 18:21:09 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4AFE1408.9040706@jacaranda.org>
Date: Sat, 14 Nov 2009 02:20:56 +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>
In-Reply-To: <20091113005419.GQ1105@Sun.COM>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1AB9B9912EDA782A24F95CFD"
Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate
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 02:20:44 -0000

Nicolas Williams wrote:
> Comments:
> 
> 1) The rest of this comment can be ignored if the use of protocol
>    extensions in draft-rescorla-tls-renegotiate is deemed to not be a
>    problem.
> 
>    I believe this problem can be fixed without using protocol extensions
>    at all.  All that has to be done is this: for re-negotiations the
>    Finished message computation changes from this:
> 
>     PRF(master_secret, finished_label, Hash(handshake_messages))
>        [0..verify_data_length-1];
> 
>    to:
> 
>     PRF(master_secret, finished_label,
> 	    Hash(handshake_messages || outer_connection_client_finished))
>        [0..verify_data_length-1];
> 
>    where outer_connection_client_finished is the client Finished message
>    for the previous/old/outer TLS connection
> 
>    There is no need to signal this!

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.

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