The CommonCryptoLib already supports TLS_FALLBACK_SCSV as a client. This prevents susceptibility to attacks on the SSL/TLS client which depend on protocol downgrades.
However, as a server, TLS_FALLBACK_SCSV isn't supported by the CommonCryptoLib. Suppose we have the case where we must provide compatibility with Internet Explorer 6.0 on Windows XP, in an environment where we do not control the user settings, and hence must provide support for SSL 3.0. Whilst IE6 will always be vulnerable to the POODLE attack because by default it will only connect over SSL 3.0, even if our server supports TLS 1.0, 1.1 and 1.2, a MITM attack can always drop any other browser down to SSL 3.0 without support for TLS_FALLBACK_SCSV.
There is a way to mitigate the POODLE attack on SSL 3.0, which is to use record splitting. Also, disabling CBC ciphers over SSL 3.0 will mitigate the vulnerability. Opera have taken the first option and Apple the second. However, record splitting causes compatibility issues due to problems in server-side implementations, and disabling CBC ciphers leaves only RC4 over SSL 3.0, which has also been broken. This leaves many browsers still vulnerable to POODLE, in particular in the mobile space, unless we disable SSL 3.0 on the server side.
Furthermore, there is a TLS 1.0 POODLE exploit affecting servers which fail to check the padding byte requirements. A server demonstrating this vulnerability and not implementing TLS_FALLBACK_SCSV will allow an attacker to roll the browser back from TLS 1.2 or 1.1 to 1.0 in order to use the exploit.
These may not the only attacks that will ever be discovered against older protocols. The draft of TLS 1.3 removes numerous deprecated features from TLS 1.2 which are seen to weaken security, such as compression, renegotiation, non-AEAD ciphers, static RSA and DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers. If and when new attacks against these features are found and TLS 1.2's (and/or earlier) security is weakened, without TLS_FALLBACK_SCSV support, users will be vulnerable.
There is a flip-side to all this. The reason protocol downgrades are possible is because early implementations of TLS 1.0, 1.1 and 1.2 were often broken. The protocol downgrade occurred when a client couldn't initiate a session with the broken server. TLS_FALLBACK_SCSV doesn't convey any version information and as such becomes a "never fall back" signal. This means that a server implementing TLS_FALLBACK_SCSV with a broken TLS 1.2 implementation will lose the ability to serve requests to the majority of clients. That's Microsoft's view of things, which is why neither IE nor IIS implement the flag.
However, given the inherent insecurity of older protocol versions, I'm not sure SAP should be following Microsoft's lead here, but instead should be following Google and Mozilla.
What is the view of the wider community on whether this flag should be implemented? Do the compatibility concerns outweigh the security advantages, or vice versa?