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

[Martin Rex <[e-mail]>]

Dr Stephen Henson wrote:
> 
> Just to be clear here: I'm not referring to an attack but where we have
> a strict patched client that refuses to connect to an unpatched server.
> That is client makes initial handshake using RI+MCSV, doesn't get RI
> back and decides this is not acceptable.
> 
> This is a scenario which is quite likely to happen at some point. Well it
> happens already in my test environment ;-)
> 
> I'm asking whether a client should send a fatal alert here so a server
> admin can get some hint of the cause or if it should just silently
> drop the connection.

If this were a _new_ spec, then I would suggest a SHOULD.

But since we're going back in time, and there seem to be a number
of implementations that are notoriously bad and sending and
receiving SSL alerts, I definitely would not want to create
any false hopes.

In the situation that you're describing, it is the updated client
that determines that it doesn't want continue talking to the old server,
and so the set of available Alerts that could make any sense
to an old server is those known to SSLv3,  IMHO.

-Martin