Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

[Yoav Nir <[e-mail]>]

On Dec 15, 2009, at 4:46 AM, David-Sarah Hopwood wrote:

> Yoav Nir wrote:
>> It would be easy to require this, but it's not compliant with the current
>> spec. The current spec says that the finished value depends on all the
>> bytes starting with the first byte of the ClientHello.
>> 
>> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but
>> adding the previous finished message is a change to the spec, one that
>> requires some sort of signaling, either with a fake cipher suite or with
>> an extension.
> 
> No, this is a misunderstanding; changing how the Finished message is
> computed *for renegotiations* does not necessarily require signalling.
> 
> Changing the way that the Finished message is computed *only* for
> renegotiations, would affect interoperability only when there is a
> renegotiation where one peer is unpatched and the other is patched.
> Under that condition, being interoperable would allow an attack.

That is just wrong. An RFC compliant client negotiating with an RFC compliant server must not get a wrong Finished message. That's changing the protocol, and it requires signaling either by a new version number or something else. You can't now change the base 1.2.

> (Some have argued for allowing patched clients and servers to favour
> interoperability over security in this case. I don't agree that that is
> desirable.)

That's not for you to decide. It's for the client and server vendors, and they may or may not pass this decision to their customers.

> Furthermore, changing the Finished message only for renegotiations is
> sufficient to prevent attacks provided that the renegotiating peer
> has been updated.

It's also sufficient to break some things.

> By itself, however, that would not allow clients to detect non-patched
> servers. It is likely, and desirable, that some clients will adopt a
> "strict" policy in which they fail an *initial* connection to a non-patched
> server. Technically, only the server->client signal is directly necessary
> for this. The client->server signal is needed to allow the server->client
> signal to be sent without the possibility of breaking unpatched clients.
> 
> (The client->server signal also allows servers to reject initial
> connections from unpatched clients. However, it's unlikely in practice
> that servers will follow that policy, and it's not necessary to prevent
> the most serious variant of the attack.)
> 
> -- 
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>