Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt

From: [email-masked]
Date: Mon, 15 Dec 2014 06:16:27 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
        Authors         : Bodo Moeller
                          Adam Langley
	Filename        : draft-ietf-tls-downgrade-scsv-03.txt
	Pages           : 8
	Date            : 2014-12-15

Abstract:
   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked] (Martin Rex)
Date: Mon, 15 Dec 2014 22:41:16 +0100 (CET)

> http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03

The current document seems still silent on the *KNOWN* problem when
a client App has been skipping TLS versions on downgrade dance.

Andrei had written about the problem here:
   http://www.ietf.org/mail-archive/web/tls/current/msg13725.html

but his suggestion: client app must NOT use FALLBACK SCSV when
skipping versions does not look like a viable solution (it removes
all protection).

MSIE 8 seems to be a browser that skips versions on downgrade dance.
MSIE 8 on Win7 with TLSv1.2 enabled, dances like this:

   TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext)

The scenario where this problem can hit is with non-malicious
middleboxes that do not recognize (and therefore do not permit)
TLSv1.2 handshakes.  I had described such a potential scenario
at the end of this message:

   http://www.ietf.org/mail-archive/web/tls/current/msg14618.html

And the problem can easily reappear with TLSv1.3.  I would not be surprised
to see TLSv1.2 servers implementing this abort TLS handshakes when they
receive a ClientHello with client_version={3,1} that contains the
TLS_FALLBACK_SCSV

-Martin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 15 Dec 2014 16:46:48 -0500

On 12/15/2014 04:41 PM, [email-masked] (Martin Rex) wrote:
> TLSv1.2 handshakes.

How do we distinguish between these non-malicious middleboxes that do
not permit TLSv1.2 because they don't recognize it and malicious
middleboxes that want to force modern peers into a downgrade by not
permitting TLSv1.2?

Do the non-malicious middleboxes use RFC 3514?

	--dkg

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 15 Dec 2014 19:42:40 -0500

> Do the non-malicious middleboxes use RFC 3514?
That's the million dollar question: how can you tell "good" bad guys
from the "bad" bad guys.

I think the answer is: you can't.

If browsers and other software want to downgrade in an insecure
fashion, then they are on their own. Don't placate them in their
efforts and weaken the system for everyone else.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Dec 2014 16:48:58 -0800

> efforts and weaken the system for everyone else.

That's kinda the point of the draft.  Let the server know so it has a
choice in the matter.

Browsers, as clients, have a choice about what TLS version they are
willing to tolerate.  With fallback, they signal that they are willing
to speak to servers and only opportunistically reach the highest
common version.  That's weaker than the guarantee that TLS can
provide, but it is their choice to do that.  You can (and have) noted
that this has drawbacks and maybe jump up and down in the hopes that
this will change something.  But it's not like the choice is made in a
vacuum.

Personally, I'm more concerned about the use of CBC modes than I am
about version downgrades in the current environment.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 16 Dec 2014 09:57:39 +0100

>    TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext)

To recap what's been previously said, I don't think that a change to the
I-D is warranted.

- The (obvious) way to make this work is to not skip versions in the
downgrade dance. Often the downgrade will be happening because of a flaky
network, not because it is required with a specific server (or induced by
an active attacker): in that case, if the server does not recognize
TLS_FALLBACK_SCSV, it is more appropriate and generally better for security
to fall back to TLS 1.1 rather than to TLS 1.0.

- I do realize that some implementors may prioritize latency improvements
over the security gain here and hence may still prefer to skip TLS 1.1. I
won't encourage that behavior, but draft-ietf-tls-downgrade-scsv-03 doesn't
disallow it. In practice, the above sequence (after TLS 1.2, attempt TLS
1.0 with TLS_FALLBACK_SCSV) should generally work well enough because
support for TLS_FALLBACK_SCSV in servers with a maximum protocol version of
TLS 1.1 will probably remain rare. To maximize interoperability, such
clients should attempt TLS 1.1 with TLS_FALLBACK_SCSV later in the
downgrade sequence (i.e., after TLS 1.0 with TLS_FALLBACK_SCSV).

Bodo

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 16 Dec 2014 01:58:06 -0800

> Martin Rex <[email-masked]<mailto:[email-masked]>>: 
>  
> To recap what's been previously said, I don't think that a change to  
> the I-D is warranted. 
>  
> downgrade dance. Often the downgrade will be happening because of a  
> flaky network, not because it is required with a specific server (or  
> induced by an active attacker): in that case, if the server does not  
> recognize TLS_FALLBACK_SCSV, it is more appropriate and generally  
> better for security to fall back to TLS 1.1 rather than to TLS 1.0. 
>  
> - I do realize that some implementors may prioritize latency  
> improvements over the security gain here and hence may still prefer to  
> skip TLS 1.1. I won't encourage that behavior, but  
> draft-ietf-tls-downgrade-scsv-03 doesn't disallow it. In practice, the  
> above sequence (after TLS 1.2, attempt TLS 1.0 with TLS_FALLBACK_SCSV)  
> should generally work well enough because support for TLS_FALLBACK_SCSV  
> in servers with a maximum protocol version of TLS 1.1 will probably  
> remain rare. To maximize interoperability, such clients should attempt  
> TLS 1.1 with TLS_FALLBACK_SCSV later in the downgrade sequence (i.e.,  
> after TLS 1.0 with TLS_FALLBACK_SCSV). 
>  
> Bodo 

I also noticed that IE11 and later excludes RC4 cipher suites from first handshake but adds them back when doing the TLS 1.0 fallback, and while there are servers that would be broken by doing it with TLS_FALLBACK_SCSV, I argue that discouraging the use of RC4 cipher suites with TLS 1.2 is a good thing.

Yuhong Bao