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

David-Sarah Hopwood <> Sat, 14 November 2009 05:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85D383A6929 for <>; Fri, 13 Nov 2009 21:30:43 -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 dTDKyxrL2Up6 for <>; Fri, 13 Nov 2009 21:30:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 07A293A67F2 for <>; Fri, 13 Nov 2009 21:30:41 -0800 (PST)
Received: by with SMTP id 9so1186867eyd.51 for <>; Fri, 13 Nov 2009 21:31:09 -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=SmO3miWTj+gBqnn6HbKMg/crf4/qpOUwwhbwQci9Kz0=; b=eY3j4h8God7CBU3b4TS++k7EKXG5P5e/zlBE3hQx1GPhOIscTMqKYNg4VHorg6Nb8d FtmFn0G4Aqhus5tVSUkNbCcifQuGiR44k0bWOVZl5PQ9bhSz2TsdGWCaq6A4PFmg3h/E i6XZkG7eNVvQNH2hl79b/m/5MoBmuyh7fQ3W8=
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=cL6c+qyfMQ6wK7M/WRwAcA/WTjWc0g5umCsUeytUAjsaCnceqxa+8NgiX36mZRHobq owIEECKEUn7a7ZHjjnCpXCmdzEyd26jykkPHKx7EBWdINZSvI6WC8LxEDsmx1LM3+2sM 9g76ycRKyOJm4aA5hid10UATvm81RFaBzN7tk=
Received: by with SMTP id z14mr593196ebh.17.1258176669189; Fri, 13 Nov 2009 21:31:09 -0800 (PST)
Received: from ? ( []) by with ESMTPS id 28sm1787340eyg.30.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 21:31:08 -0800 (PST)
Sender: David-Sarah Hopwood <>
Message-ID: <>
Date: Sat, 14 Nov 2009 05:30:57 +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="------------enig2CBC45733CD3661485B0E499"
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 05:30:43 -0000

David-Sarah Hopwood wrote:
> 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.

No, on further consideration this argument is wrong. Since adding the
verify_data into the Finished hashes would only happen for renegotiations,
it cannot cause any interoperability failures on an initial handshake.
It would cause a handshake failure on a renegotiation, if only the client
or only the server has been patched.

Note that a handshake failure in that case doesn't necessarily result in
an interoperability failure. That's because many clients will fall back
to reconnecting on a new session, if a renegotiation fails. In fact,
implementors of web browser clients essentially have no choice but to
do this if they want to interoperate with many web servers (the situation
might be different for non-HTTP protocols) [*].

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.

Important point: TLS- or extension-intolerant servers are all unpatched.
If a client implementor considers it necessary to interoperate with
such servers, then that would not be consistent with a policy of refusing
to connect to unpatched servers. Suppose that we 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.

[*] There is a corner case in which this argument might not apply --
    the "Step-Up" protocol, where old versions of the Netscape browser
    would initially offer only 40-bit ciphersuites, and then renegotiate
    to use a stronger ciphersuite if they see that a bit is set in the
    certificate. Such browsers are obviously unpatched, and will fail to
    renegotiate with a patched server that is using a Step-Up certificate.

    Note that "Step-Up" is different from "Server-Gated Cryptography"
    (SGC), in which the client never completes the first handshake and
    reconnects in a new session:
    SGC does not rely on renegotiation.
    (Verisign/Thawte sells certs that support both and does not
    distinguish between them; don't be confused by that.)

    Step-Up was a Netscape proposal, and SGC was from Microsoft.
    I don't think that Internet Explorer ever implemented Step-Up (as
    opposed to SGC). Netscape only implemented it in versions 3.x and
    4.x, which have numerous arbitrary code execution bugs that would
    be easier to exploit. So this is not a significant issue at all --
    any sites that are still using Step-Up certs, would be well advised
    to just patch their servers and tell their users to stop using such
    old browser versions.

David-Sarah Hopwood  ⚥