Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Martin Rex <[e-mail]>]

Kemp, David P. wrote:
> 
> Amazon and Google are free to accept SSLv2 as well as TLSv1.x-unpatched
> (minor MSbit unset) if they perceive the benefit of communicating to be
> greater than the risk of being attacked.   That has no bearing on
> whether the protocol spec for TLSv1.x-patched requires aborting
> connections with bozo endpoints, which of course it should.   Service
> providers/consumers can make their own choice of which protocol versions
> and ciphersuites to accept, with the knowledge that more restrictive
> choices will lock out some endpoints.   It has always been thus.

I don't understand what you mean.

If by "accept TLSv1.x-unpatched" you mean initial handshakes with the
installed base of SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 without the
renegotiation protection then your assertion is flawed.

There is absolutely _NO_ known security problem and no vulnerability for
a server to accept an initial handshake with the existing SSLv3, TLSv1.0,
TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
message does neither contain SCSV nor an empty extension RI.

The possibility for an "attack" where an old client's renegotiation
handshake is proxied into the initial handshake of a server is of
no concern to the server.  That's purely a client issue and has the
prerequisite that the client completely botches the server authentication
on the initial handshake and is equivalent in effectiveness to XSRF, XSS
and server impersonation -- something that protected TLS renegotiation
can not protect from.


-Martin