Re: [TLS] Fallback SCSV summary

["Yngve N. Pettersen" <[e-mail]>]

Hello all,

Below is some statistics that I did not complete gathering until this  
week, related to something I think was mentioned in the SCSV discussion  
thread a couple of weeks ago: Some servers are apparently intolerant to  
the SCSV, and attempts to connect using the SCSV will fail.

My TLS Prober runs indicates that 2.5% of servers will fail a connection  
using the SCSV when it is placed at the last position in the cipher suite  
list, and 4.9% will fail if it is placed at the beginning of the list. In  
fact, while a sample of just two weeks is problematic, these numbers  
appear to be increasing, as one week earlier the numbers were 2.1% and  
4.0%, respectively.

I also tested three other alternative SCSVs,placed at the end of the  
cipher suite list, and 0.6% of the tested servers did not tolerate each of  
those.

As a comparison, 1.3% of the tested servers are extension intolerant when  
the client indicates TLS 1.x.

The combination of SCSV intolerant and extension intolerant servers appear  
to be less than 0.1% of the sample. As I have not yet managed to pin down  
a server with this combination that fails during actual testing with an  
SCSV supporting browser, I am wondering if this combination is at least  
partly due to false postives, or if they fail at specific TLS versions.  
Further testing may be necessary to find out if that is so.

14.4% support the SCSV at this time.

Related to TLS 1.3 and fallbacks: Essentially all of the SCSV supporting  
servers failed when the SCSV is used at the start and for the server's  
highest supported version; less than 0.1% did so for the SCSV at the end.

Also, 2.4% of servers are intolerant for the TLS 1.3 version indication,  
half of them are Renego patched.

On Sat, 08 Nov 2014 02:52:37 +0100, Joseph Salowey <[e-mail]> wrote:

> Below is my summary of the fallback SCSV issue with some suggestions.
> Since I'm weighing in on the text as an individual I'm asking Sean to
> finish up the consensus process on this draft.
>
> I've gone through he SCSV comments and I think the following issues need  
> to
> be resolved:
>
> 1.  The draft does not really state that the fallback SCSV is really a  
> hack
> and that standard version negotiation should really be encouraged.  Here  
> is
> some text that could go into the introduction:
>
> "The fallback SCSV defined in this document is not suitable substitute  
> for
> proper TLS version negotiation. TLS implementations need to properly  
> handle
> TLS version negotiation and extensibility mechanisms to avoid the  
> security
> issues and connection delays associated with fallback mechanisms."
>
> 2.  The current draft will cause TLS connections to fail if a downgrade
> happens for any reason.  This will result in additional retries even if  
> the
> server is willing to continue at the lower version.  An alternative using
> extensions has been described to allow the server to communicate the  
> status
> of the downgrade back to the client and let the client decide whether to
> continue.
>
>> From reading the list I don't think we have consensus to abandon the the
> SCSV approach.  The SCSV mechanism is simpler and it does not rely on
> extensions which have been a reason for server failures in the past.
> However, I think the draft can better describe the conditions of when the
> client SHOULD include the SCSV and what the client SHOULD do if it  
> receives
> an inappropriate_fallback alert.  Here is some proposed text for section  
> 4
> and security considerations:
>
> Section 4
>
> "If the client receives an inappropriate_fallback alert then the server
> intends to support a higher version and the client should retry with the
> highest version it supports.   Implementors should review the security
> considerations section before deciding to make a connection with a lower
> version without including the TLS_FALLBACK_SCSV.
>
> Security Considerations
>
> "Section 4 does not require client implementations to send
> TLS_FALLBACK_SCSV in any particular case, it merely recommends it;  
> behavior
> can be adapted according to the client's security needs.  However, it is
> important to remember that omitting the TLS_FALLBACK_SCSV leaves the TLS
> connection vulnerable to version rollback so it is not recommended to  
> omit
> the SCSV unless the negotiated version provides an acceptable level of
> protection.
>
> For example, during the initial deployment of a new protocol version
> (when some interoperability problems may have to be expected),
>    smoothly falling back to the previous protocol version in case of
>    problems may be preferrable to potentially not being able to connect
>    at all: so TLS_FALLBACK_SCSV could be omitted for this particular
>    protocol downgrade step.
>
>    However, it is strongly recommended to send TLS_FALLBACK_SCSV when
>    downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
>    weaknesses that cannot be addressed by implementation workarounds
>    like the remaining weaknesses in later (TLS) protocol versions."
>
> 3.  The introduction should indicate that the Fallback SCSV also applies  
> to
> DTLS.
>
> 4.  The IANA considerations section needs to allocate the number for the
> alert:
>
> "IANA is asked to assign the following value in the TLS Alert Registry  
> for
> use with TLS and DTLS.
>
> 86  inappropriate_fallback Y [RFC TBD]"


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/