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

[Nicolas Williams <[e-mail]>]

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. 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) [*].

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).

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

> 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.

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.

Nico
--