Re: [TLS] simplistic renego protection

[Nelson B Bolyard <[e-mail]>]

On 2009-11-19 11:05 PST, David-Sarah Hopwood wrote:
> Nasko Oskov wrote:

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

I must have missed the message wherein "lenient server" was defined.
Is it a server that accepts client hellos without any signal that the
client has been upgraded, but merely refuses to renegotiate with such a
client?

IOW, is it the kind of server that numerous vendors are shipping now,
that recent patches to open source have just created, one that refuses to
renegotiate at all but still accepts old style client hellos?

Is someone proposing to abolish them already?

> Remember, rejecting a renegotiating ClientHello does not necessarily lead
> to an interoperability failure; it only does so if the client will not
> reconnect.

By definition, the alert that rejects a renegotiating client auth
(no_renegotiation) is a warning alert.  It leaves the previous TLS
connection and session state intact and able to continue.  So IINM, it does
not lead to an interoperability failure unless the client chooses to treat
that alert as fatal, despite being a warning, AND refuses to reconnect.
Right?