Hello Rob,
CommonCryptoLib does not support TLS_FALLBACK_SCSV as a client. Currently, there are no client applications on top of CommonCryptoLib, which would do a downgrade dance. So there is no need to protect against it on the client side. Right, we do not even support TLS_FALLBACK_SCSV on server side. Implementation of RFC 7507 as is, may cause severe interoperability problems and we did not see a straight way out. Upon receipt of TLS_FALLBACK_SCSV, the server has no other chance than to cancel the handshake. TLS_FALLBACK_SCSV gives a server too few information about the client's downgrade dance to take a better decision than to slam the door, crying "you are a downgrade dancer". Now it's up to the client to try an upgrade dance.
Implementation of TLS_FALLBACK_SCSV on server side does not make sense, if no client uses it. Unfortunately, the great downgrade dancers among popular browsers do not support it.
Even if they did, this would not resolve any inter-op problems: There are servers, who slam the door without a whisper upon receipt of a ClientHello.version==TLS1.2 . Or, they are allergic to TLS extensions but omit to send an appropriate alert.
What happens?
1. The client tries TLS1.2 with some extensions,
2. the server gets stuck and swallows the alert,
3. the client sends a new Hello with the SCSV in it, the server answers with an inappropriate_fallback - alert
4. Now, RFC 7507 says, that a client should retry with the highest TLS version it supports.
5. Thus, RFC 7507 advises the Client to return to step 1.
They won't ever come together.
Hope that helps
Kindest regards
André