Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal

David-Sarah Hopwood <> Sat, 14 November 2009 07:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74A1A3A6826 for <>; Fri, 13 Nov 2009 23:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hFHv4skb5rGh for <>; Fri, 13 Nov 2009 23:04:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 158AD3A681B for <>; Fri, 13 Nov 2009 23:04:09 -0800 (PST)
Received: by with SMTP id 9so1207962eyd.51 for <>; Fri, 13 Nov 2009 23:04:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=jlQcez48oBUR/034X2pO4TaJjlJKEFGWW/3k2SS5NXI=; b=ET5VTGPVFZ+1/iHYPs80vWttjdneBMoNcCznXF6JpQiUeWdkRbRYu6yBqEoGUXyP/k ePEOwPTetstHZGDcEDkRTzPaxq4DuFqjk0jn6Qp+pU8yKWbuRZ4g8/qtVUej8ieRAbrL Z+aK2Tb6zfHB72w7c3QOqE77sHNA3hyAMy72s=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=WQbqHzcFdYgqLOQZTT4l2s0gtWO1zmeJJ0NGuEwf467u3TU4re+QgyuUG/hX+lv+EQ HSWwNYVWN61axQ9zoOUXX2qEQFqlfJvUctBFzmjpFEjZq0gBjkLzRaynbjCkpFojJUX1 foeDI1y4658NlYpb31p3V6vdVI5XYcuGHa3mg=
Received: by with SMTP id s7mr3362814ebb.80.1258182277254; Fri, 13 Nov 2009 23:04:37 -0800 (PST)
Received: from ? ( []) by with ESMTPS id 10sm2549545eyd.7.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 23:04:36 -0800 (PST)
Sender: David-Sarah Hopwood <>
Message-ID: <>
Date: Sat, 14 Nov 2009 07:04:19 +0000
From: David-Sarah Hopwood <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/20070326 Thunderbird/ Mnenhy/
MIME-Version: 1.0
References: <> <20091113005419.GQ1105@Sun.COM> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig38119453F46A2BEF39865243"
Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Nov 2009 07:04:11 -0000

David-Sarah Hopwood wrote:
> On the other hand, consider the case of a patched client performing an
> initial handshake with an unpatched server. If an extension is not used,
> then there is no way for the client to tell that the server is unpatched,
> and the connection might succeed even though an attack is taking place.
> Using the extension would give patched clients the option of refusing to
> connect to unpatched servers.
> The converse situation, where a patched server does not know whether it
> is talking to a patched or unpatched client, is probably less significant:
> an attack can only succeed in that case if the client does not check the
> server's certificate, in which case a MITM attack is possible anyway.

Ah, but *if* the unpatched client does not properly check the certificate,
then the attack that is described here by Martin Rex:


would be possible only as a result of the renegotiation flaw; it is not
possible just using an ordinary MITM attack.

More specifically, the difference between this and an ordinary MITM is
that in the latter, the attacker cannot *both* control a prefix of the
session, and cause the server to be convinced that the client is
authenticated by a particular client cert.

The problem here is that if the server does not see the extension in the
ClientHello, and it chooses to break the connection in order to avoid the
possibility of the above attack, then it might be unnecessarily breaking
a connection with a patched client that was just unwilling to send the

Still, that's no worse than the situation with the current
draft-rescorla-tls-renegotiate. So I think that what I suggested:

> [...] only use an extension
> as an advisory of patched status (i.e. say that an empty extension SHOULD
> be sent if patched), but add the verify_data into the Finished hashes
> unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, the
> concerns about extensions potentially breaking some servers, and the
> concerns about lack of an extension potentially resulting in a security
> weakness (due to a client being unable to tell whether a server is patched),
> would only arise in mutually exclusive sets of cases.

is still an overall improvement.

David-Sarah Hopwood  ⚥