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

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

Nicolas Williams wrote:
> On Sat, Nov 14, 2009 at 05:30:57AM +0000, David-Sarah Hopwood wrote:
>> David-Sarah Hopwood wrote:
>>> 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.
> 
> Right.
> 
>> Note that a handshake failure in that case doesn't necessarily result in
>> an interoperability failure. [...]
> 
> Right.
> 
>> 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.
> 
> Irrelevant: nothing that goes over the first connection should be at
> risk or sensitive, provided that the client did authenticate the server
> OR, if an anon-anon cipher suite was used, (that the client refrained
> from sending confidential data AND the client did not take destructive
> action based on data from the server).

No, that's not correct. The client's session may have been prefixed by
data chosen by the attacker. Therefore everything sent in that session is
at risk.

This depends to some extent on the application protocol, but I would
expect almost all protocols to be potentially vulnerable -- although not
all implementations.

> It's OK for the client to learn that the server is unpatched when it
> tries to re-negotiate.

An attack can occur even against connections of a client that *never*
renegotiates, if it is connecting to an unpatched server.

>> 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.
> 
> Right.
> 
>> Important point: TLS- or extension-intolerant servers are all unpatched.
> 
> Yes.  But I get the feeling that some folks think it will be easier to
> patch them than to upgrade them.  My proposal is particularly useful
> then, since it can be applied even to SSLv3.

The easiest patch is to just disable renegotiation. If you're going to
do anything more complicated than that, I don't think it makes any sense
at all to leave the server in a state where it is still TLS- or
extension-intolerant.

Note that we don't need such servers to support TLS; only to tolerate a
TLS ClientHello with extensions, and perform version negotiation correctly
for whatever version(s) they do support.

> NOTE: I'm not trying to force a design change at this late stage.  I had
>       a caveat at the top of my proposal that it should only be
>       considered if the use of extensions turned out to be problematic.

Yes, that also applies to my suggestion of adding in the Finished hashes
unconditionally for renegotiations, and treating the extension as
advisory. It would be helpful to know to what extent implementors of
commonly used clients actually still think that it is problematic to use
extensions on an initial handshake. (For HTTPS, it would be particularly
interesting to know what Internet Explorer's behaviour would be once it is
patched.)

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