Re: [TLS] simplistic renego protection

[Nasko Oskov <noskov at microsoft.com>]

David-Sarah Hopwood wrote:
>>>> This is a non-sequitur. Lenient clients don't need to send the 
>>>> extension in the ClientHello of an initial handshake. Strict clients 
>>>> must not be able to talk to unpatched servers, by definition.
>>> I must be misunderstanding the attack. Why is the attack not possible 
>>> even when client doesn't send the RI extension on initial handshake?
>> 
>> Because the server knows that the connection is a renegotiation from 
>> its point of view, and therefore it rejects any handshake that doesn't 
>> contain the extension.
>> 
>>> If the MiTM sends a client hello to the server that has no extension, 
>>> then the server has no way to drop the connection. This will require 
>>> a strict server to prevent the attack and strict server config will 
>>> not be reality for a long time. What am I missing?
>> 
>> That, in the RI approach, strict server config is essential from the start.
>
>Point of clarification: "strict server" here means that the server does not
>accept *renegotiations* with an unpatched client. It still accepts initial
>handshakes.

Thanks for the clarification. We seem to differ in the definition of strict
server config. This clarifies it.

You are assuming then that admins will have to upgrade any clients that do
renegotiation before they upgrade their servers, otherwise there will be
interop problem. Am I correct?
This will mean that admins for sites that require client authentication will
not be upgrading their servers until their entire set of clients have
patched browsers. There is an option to rearchitect the site, but that 
might not be possible.

>A "strict client", OTOH, will refuse to make even initial connections to an
>unpatched server. So support for lenient (as well as strict) clients is
>certainly necessary, but whether support for lenient servers is needed is
>much less clear.

Great! We are in consensus on the client definition of lenient and the need
to support that.

>> We haven't yet established whether the ability to support lenient 
>> servers is a requirement. Eric has argued against allowing that; so have I.
>> If lenient servers are allowed, then I think it will take *much* 
>> longer until the vulnerability is eliminated from most connections.

There seems to be 3 different ways to define the server behavior:
* allow anyone
* don't allow renegotiation from unpatched clients
* don't allow initial negotiation from unpatched clients

We should be clear on which ones we call strict and lenient.

Nasko