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

[David-Sarah Hopwood <[e-mail]>]

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:
    <https://bugzilla.redhat.com/show_bug.cgi?id=533125#c24>
    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  ⚥  http://davidsarah.livejournal.com