Based on Recommendations in the original research:
https://www.openssl.org/~bodo/ssl-poodle.pdf
If man-in-the-middle (MITM) intercepts communication, assuming client's "Hello" with ciphers propagates in clear, what would preclude MITM from removing TLS_FALLBACK_SCSV flag during downgrade dance (thus rendering the mechanism proposed inefficient)?
It is not fully efficient anyway (since existing SSL3.0 browsers would be affected - otherwise its support could be fully removed on server side): just in the light of Chrome promotion under TLS_FALLBACK_SCSV pretext...
Even if in clear, it is still signed. If a MiM modifies this flag then Finish that sign/hash over all handshake won't match. Client will detect it as an handshake failure.
Your answer is in mailling list here : http://marc.info/?l=openssl-users&m=141355872416212&w=2
You will find some information about TLS_FALLBACK_SCSV flag here: http://wiki.opensslfoundation.com/index.php/SSL_MODE_SEND_FALLBACK_SCSV
Basicaly action done by MiM to force client to downgrade is network related or make TLS handshake fails, it can then manage to force a downgrade. But MiM does not manage to tweak the full handshake, due to sign/hash.