Hi,
 
I just finished a scan of Alexa top 1 million websites to test for TLS version intolerance. I hope this information can be useful in the discussion of downgrade SCSV.
 
For each site, I made at most four attempts with the following order to fallback:
(TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS 1.0, TLS 1.0)
where the first is TLS record layer version, and the second is Client Hello version.
 
Here is the result:
(1) Number of sites scanned: 1,000,001
(2) Number of DNS Error: 45,402
(3) Number of sites that refuse TCP connection on port 443 (RST, timeout): 289,334
(4) Number of sites that fail sending ServerHello in all 4 attempts: 238,846
(5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%)
(6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)
(7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%)
(8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a lower record layer version does improve compatibility a lot. An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate certificates nor check the integrity of handshakes. I closed the connection immediately after receiving ServerHello.
 
If my data is accurate, I am against making downgrade SCSV a proposed standard, and I believe browsers should stop insecure fallback. At least, the percentage of TLS 1.2 intolerant sites is low enough. For TLS 1.3, I think maybe browser vendors can announce a deadline, after which fallback to TLS 1.2 will no longer be accepted? Or simply break them? Both are reasonable to me. Also I want to point out that if even as few as 1.6% sites won't upgrade their servers, can we count on most of the rest 98% supporting SCSV?
 
P.S. The statistic of Server Hello version is:
(9) SSL 2.0: 0 (0.0%)
(10) SSL 3.0: 413 (0.1%)
(11) TLS 1.0: 176051 (41.3%)
(12) TLS 1.1: 2261 (0.5%)
(13) TLS 1.2: 247668 (58.1%)
(14) Above TLS 1.2: 26 (0.0%, malformed response)
 
The raw data of my scan result can be downloaded from here: https://onedrive.live.com/redir?resid=8D6F364311BB35F2!110&authkey=!AI5Kno4OzsXbkII&ithint=file%2czip.
 
Best,
Xiaoyin
 
 
> Date: Mon, 19 Jan 2015 12:58:28 -0800
> From: brian@briansmith.org
> To: mrex@sap.com
> CC: tls@ietf.org
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
> 
> Martin Rex <mrex@sap.com> wrote:
> > Permitting the server to continue the TLS handshake with
> > ServerHello.server_version = (ClientHello.client_version +1)
> >
> > This would be an extremely small change, but a *HUGE* improvement to this
> > proposal and make TLS handshakes _succeed_, i.e. promote interop.
> 
> This doesn't work. Consider this example of how your suggestion would work:
> 
> Client and server both support TLS 1.2.
> 
> Client attempts TLS 1.2, receives RST.
> Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
> Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.
> 
> This results in a downgrade from TLS 1.2 to TLS 1.1.
> 
> > Should a TLS client be unsatisfied with the properties of the resulting
> > TLS session, that client could still decide attempting a new/different
> > handshake by proposing additional features in ClientHello (that should
> > have never been absent from ClientHello in the first place).
> 
> I think at this point browsers are only "satisfied" when the
> connection is TLS 1.2 using an AEAD cipher suite, but they still feel
> the need to support servers that only support worse crypto. So, this
> part of the idea doesn't work either.
> 
> > It's not that suggestions to improvement to this proposal haven't been
> > made.  It's really disappointing to see this go _through_ the TLS WG
> > and not seeing any improvement whatsoever, and then going straight
> > to asking for rubber-stamping it.
> 
> I don't think that the characterization of "rubber-stamping" is
> accurate or helpful for moving the discussion forward.
> 
> I DO think it would be useful for the IETF to wait ~8 weeks to see the
> results of Firefox's experiment in disabling the non-secure fallback,
> and to see the results of studies of TLS 1.3 intolerance with
> ClientHello messages with different record-level version numbers. If
> it turns out to be reasonable for web browsers to stop doing the
> non-secure fallback, then it really would be bad policy for IETF to
> make the downgrade a proposed standard, because the downgrade SCSV
> will always be limited in effectiveness by the fact that a huge number
> of servers will not deploy the downgrade SCSV mechanism any time soon.
> Still, it's not clear yet that web browsers can reasonably stop doing
> the non-secure fallback, so I think it makes sense to have the
> downgrade SCSV mechanism ready as insurance.
> 
> Cheers,
> Brian
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls