Re: [TLS] Redefine Finished message for TLS 1.3 ?

David-Sarah Hopwood <david-sarah@jacaranda.org> Sun, 15 November 2009 03:38 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 468C33A6912 for <tls@core3.amsl.com>; Sat, 14 Nov 2009 19:38:09 -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 9LN1FDxjKNAV for <tls@core3.amsl.com>; Sat, 14 Nov 2009 19:38:08 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 2BCE23A690B for <tls@ietf.org>; Sat, 14 Nov 2009 19:38:08 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 9so1502067eyd.51 for <tls@ietf.org>; Sat, 14 Nov 2009 19:38:36 -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=5b56wk6hAzjwQ0zt9hoc/qqPwvwTxRsR3MWgY//uagk=; b=r1ppqCfaLcXP6ZGDviLSv3h8U+3ixVctDJ0IA0zcxVD8Qp2SFlun94niVRAzQjxWp2 U1MEqaqiYV+1sAIF7YngQiAW1JPoOLOnY/OWogDAp6cF5shnrPd7Nc/BMG3lVf9qrmSC 0TZLWJtGD3Nfdfg4Bn56Y84QEfoP7XTiJO1hM=
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=T3GgcDN5JcuEtaDyBqNawViedM45XnTYKGZZdwmE1lHxSbCpQluanbErhndyg9a8mX 58s5pvS1yAH0pRvhBJsKkOyws/x4UE9y0JozvSW4mEv+QHWGRwVftoca5JNLAz06sykk C+rXSA7BaWySmC+c+112m3Mw9LYi8+GEen4Rg=
Received: by 10.213.23.146 with SMTP id r18mr3679003ebb.74.1258256316300; Sat, 14 Nov 2009 19:38:36 -0800 (PST)
Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 24sm3055918eyx.37.2009.11.14.19.38.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 19:38:35 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4AFF77B1.1000106@jacaranda.org>
Date: Sun, 15 Nov 2009 03:38:25 +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: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp> <4AFF6EFA.6080508@pobox.com> <4AFF7071.9050102@extendedsubset.com>
In-Reply-To: <4AFF7071.9050102@extendedsubset.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enigB6AF7680F2DF7DE694BDD837"
Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ?
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: Sun, 15 Nov 2009 03:38:09 -0000

Marsh Ray wrote:
> Michael D'Errico wrote:
>> changing the Finished message calculation for renegotiations
>> does not protect a patched client when talking to an unpatched
>> server.
> 
> A patched client in 'secure' mode will have to refuse to handshake with
> an unpatched server.

Yes, but Michael's point was that changing the Finished message
calculation alone does not allow the client to know that it is
communicating with an unpatched server. The client's handshake is
initial, so it does not include the verify_data in the Finished
hash calculations, and neither does the server.

That's why a separate indication of patched status is needed
if you want to support the policy of refusing to connect to an
unpatched peer. OTOH, if you change the Finished message calculation
then this signalling is *only* needed to support that policy.

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