Subject: [TLS] Fallback SCSV summary

From: Joseph Salowey <[email-masked]>
Date: Fri, 7 Nov 2014 17:52:37 -0800

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]"

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 08 Nov 2014 04:37:51 +0100

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.

-- 
Sincerely,
Yngve N. Pettersen

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

---

From: Hubert Kario <[email-masked]>
Date: Mon, 10 Nov 2014 17:48:24 +0100

On Saturday 08 November 2014 04:37:51 Yngve N. Pettersen wrote:
> list, and 4.9% will fail if it is placed at the beginning of the list.

I'm assuming you mean a test with ClientHello that otherwise includes ciphers 
that were verified as supported by server, includes the RC4 ciphers in the 
first 64 ciphers and is smaller than 256 bytes.

In other words, tested in a way that won't trigger other common bugs.
-- 
Regards,
Hubert Kario

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 10 Nov 2014 21:01:22 +0100

Thanks for the comments!

> issues and connection delays associated with fallback mechanisms."

Added to the introduction (but s/fallback mechanisms/fallback retries/).

> version without including the TLS_FALLBACK_SCSV.

Added to Section 4:

" [...] SHOULD include the TLS_FALLBACK_SCSV cipher suite value in
ClientHello.cipher_suites; see Section 6 for security  considerations for
this recommendation."

and

"Fallback retries could be caused by events such as network glitches, and a
client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive
an inappropriate_fallback alert in response, indicating that the server
supports a higher protocol version. Thus, if a client intends to use
retries to work around network glitches, it should then retry with the
highest version it supports."

> [...] 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.
>

Added to Security Considerations:

"It is important to remember that omitting TLS_FALLBACK_SCSV enables
downgrade attacks, so implementors must take into account whether the
protocol version given by ClientHello.client_version still provides an
acceptable level of protection."

> DTLS.

New wording in the introduction:

"This specification applies to implementations of TLS 1.0 [RFC2246], TLS
1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of DTLS 1.0
[RFC4347] and DTLS 1.2 [RFC6347]."

> 4.  The IANA considerations section needs to allocate the number for the

Oops, good point. Done.

Bodo

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 10 Nov 2014 21:19:03 +0100

> In other words, tested in a way that won't trigger other common bugs.

The Client Hellos in this case are usually smaller than 160 bytes, and  
includes the same cipher suites and extensions that the server was tested  
with originally to determine support for the TLS version and support for  
extensions. IOW, the Client Hello is just 2 bytes longer than those  
original Hellos.

For reference, 13% of the servers intolerant against the SCSV at the end  
were also failing a 256 byte Hello, and 8% of those failing at the start  
also failed the 256 byte test.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 10 Nov 2014 21:28:19 +0100

Yngve N. Pettersen <[email-masked]>:

> highest supported version;

For OpenSSL servers, this is a known bug (fixed in the next release) --
when going through the list of cipher-suites, the server-side code fails to
look anywhere after the SCSV.

> less than 0.1% did so for the SCSV at the end.
>

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 10 Nov 2014 21:40:14 +0100

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.

So ... unless I'm misunderstanding what you describe here, these servers
plainly don't tolerate new (= unknown, to them) cipher suites in the
list?!  Interesting.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Nov 2014 12:45:53 -0800

On 10 November 2014 12:40, Bodo Moeller <[email-masked]> wrote:
> plainly don't tolerate new (= unknown, to them) cipher suites in the list?!
> Interesting.

There's a suggestion that some implementations only look at the second
byte.  A legacy of SSLv2, I believe.

I'm not going to lose sleep over this.  The SCSV fortuitously or
otherwise, has a zero value on the second byte, which those
implementations might recognize as TLS_NULL_WITH_NULL_NULL.  Changing
that might fix some of the issues, but I'm not sure that I want to
take the cost.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 10 Nov 2014 22:02:43 +0100

> list?!

> byte.

Oh, that. Good point. Obviously, these servers will have other problems too
(just due to collisions between deployed cipher suites in the Standards
Action range and the Specification Required space), and failing the entire
handshake if one of the cipher suites supposedly suggested by the client
seems suspect is broken too, but right, that kind of issue may explain why
more servers reject our concrete SCSV value than other potential SCSV
values.  (It's not clear that you'd even *want* to interoperate with such
servers ... keeping them around would make it harder to add new actual
cipher suites.)

>   A legacy of SSLv2, I believe.
>

Actually, SSL 2 cipher suites ("cipher kinds") had three bytes.  It's
probably simply a legacy of all SSL 3.0 cipher suites having the common
first byte 0x00.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Nov 2014 15:24:06 -0800

On 10 November 2014 13:02, Bodo Moeller <[email-masked]> wrote:
> It's not clear that you'd even *want* to interoperate with such servers ...
> keeping them around would make it harder to add new actual cipher suites.

I tend to agree.  We have to be cautious about making a blanket
statement, but visible bugs like this are often strongly correlated
with other more insidious bugs (and things that are arguably not bugs,
like support for SSLv3).