This is not quite the same discussion as in the TLS Working Group, but I certainly think that the claim that "new SCSV does not help with [the SSL 3.0 protocol issue related to CBC padding] at all" is wrong, and that my statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is right.
Yes, regardless of what you do, SSL 3.0 still has that vulnerability. The vulnerability is best avoided by not using SSL 3.0. One way to avoid SSL 3.0 is to entirely disable it. Another way to avoid SSL 3.0 at least in certain scenarios, in case you are not ready to entirely disable it, is to make use of TLS_FALLBACK_SCSV. Deploying TLS_FALLBACK_SCSV has further benefits that indeed have nothing to do with CVE-2014-3566, and deploying TLS_FALLBACK_SCSV will certainly not fully protect against CVE-2014-3566 if you continue to allow SSL 3.0, given that TLS_FALLBACK_SCSV requires client-side *and* server-side support to achieve anything -- so TLS_FALLBACK_SCSV is not *the* fix for CVE-2014-3566. However, in the current implementation landscape, if you *do* have both client-side and server-side support for TLS_FALLBACK_SCSV, this provides perfectly fine protection against CVE-2014-3566 for these connections; so CVE-2014-3566 is a very good reason to deploy TLS_FALLBACK_SCSV support now (or to have it deployed a couple of months ago). In other words, "TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566". Bodo
