Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

From: Marsh Ray <[email-masked]>
Date: Mon, 3 Feb 2014 22:08:09 +0000

Forgive me if this has been discussed before, sometimes I have trouble
wrapping my head around all this version negotiation stuff.

The draft http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 states:
>  All unnecessary protocol downgrades are undesirable (e.g., from TLS
>  1.2 to TLS 1.1 if both the client and the server actually do support
>  TLS 1.2); they can be particularly critical if they mean losing the
>  TLS extension feature (when downgrading to SSL 3.0).

While this is certainly true, it is also 'undesirable' to increase
the rate of spurious handshake failures for clients. So it's
a lesser-of-two-evils tradeoff. Absent a plausible attack, an
increased rate of total interop failure seems like the more
tangible and quantifiable evil.

So what's the attack that this SCSV is trying to solve?

Could someone please give a scenario in which:
A. The legitimate client supports ver > TLS 1.0.
B. The attacker is able to trigger client fallback to ver <= TLS 1.0
C. *All* servers having the private key for a valid cert support
   ver > TLS 1.0.
D. The attacker is able to exploit some weakness with the
   downgraded ver <= TLS 1.0 connection that he
   can *not* exploit in ver > TLS 1.0.
E. The attacker is *not* able to actually impersonate the legitimate
   server over this downgraded (ver <= TLS 1.0) connection.

Rationale:
A. The value of this proposal comes when using post-TLS 1.0 aware clients.
B. Obvs.
C. The value of this proposal comes when using post-TLS 1.0 aware servers,
   but if any legitimate server only supports ver <= TLS 1.0, the attacker
   can forward the initial connection to that server.
D. Otherwise, what would he gain by the downgrade?
E. If the attacker could successfully impersonate the legitimate server
   over the downgraded connection, he would simply ignore the SCSV,
   right?

I don't mean for this to sound like a rhetorical question, I'd just like
to see what such a scenario would look like. I'm personally still on the
fence about this one.

Thanks,

- Marsh
--------------------------------
My personal opinions only, usual disclaimers apply.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2014 14:20:06 -0800

On Mon, Feb 3, 2014 at 2:08 PM, Marsh Ray <[email-masked]> wrote:

> The draft http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01states:

The example I would use here is:
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05

Because this draft uses an extension for signaling, if the attacker
can convince the client that the server is extensions-intolerant
and the server reconnects over SSLv3, then the attacker has
forced you to into using the old MAC/Encrypt order. He can
do this even if he couldn't impersonate the server because the
fallback in question is done at the application layer not via the
TLS version negotiation mechanisms.

Does this make sense? Note that this is distinct from the
cost/benefit calculus of whether it's better to use this extension.
It's just intended as an example of a realistic attack vector.

-Ekr

---

From: Bodo Möller <[email-masked]>
Date: Mon, 3 Feb 2014 23:20:39 +0100

Marsh Ray <[email-masked]>:

>    server over this downgraded (ver <= TLS 1.0) connection.

Examples:

- The CBC cipher suites in TLS 1.0 are more broken than in TLS 1.1 and
later (thanks to explicit IVs). They're even worse in SSL 3.0.

- If you fall back to SSL 3.0 without extensions, you lose various features
(for example, can't negotiate curves for ephemeral ECDH), not all of which
have even been specified yet.

Bodo

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sun, 09 Feb 2014 17:40:53 +0100

Hi,

Sorry about the delay, I did not have the data available until this week,  
due to hardware problems.

On Mon, 27 Jan 2014 12:03:29 +0100, Bodo Moeller <[email-masked]> wrote:

>> 2) The use of this SCSV require both client and server to be updated to
>> understand the SCSV. The deployment of such a fix is going to take a
>> minimum of 5-10 years (The renego patch, fixing a major security
>> vulnerability, have only recently passed 80%, more than 3 years after it
>> was released). I would prefer a solution that only require one party,  
>> the
>> client, to be updated.
>>
>
> Your 5-10 year estimate is for wide deployment.  Narrower deployment can
> happen much quicker: once you update your client, you get the expected
> protection for all connections to those servers that have been updated.
>  Even if that's just 1% of *all* servers, that 1% might include those
> servers you care about most.  A percentage of servers isn't a very useful
> metric (and even a percentage of appropriately specified "sessions"
> couldn't do justice to the fact that security will be much more important
> for some of these than for others).

This depends on whether they are on your list of most important sites.

Taking the renego deployment as an example, at present, 4 years after  
publication of RFC 5746, 16.7% of the 526000 servers I sampled yesterday  
are not patched (54.7% vulnerable). In the Alexa top million segment the  
unpatched rate was 17.97% (51% vulnerable), in the top 1% (10K) the  
unpatched rate is 25.7% (44% vulnerable). For reference, a year after the  
publication of RFC 5746 52% of (327K) servers were unpatched, 67.7% of  
Alexa top 10K and 77% of top 100 weren't.

Based on the current patch rate, 7.3% per year, we are looking at at least  
another 2.5 years before all servers are patched. That is 6.5 years after  
release of the RFC, for what can be considered a critical patch.

I doubt this SCSV will be considered a critical patch, so it will be most  
likely be considered something that is added to the newest versions of  
servers, probably versions that is rolled out a year or (more likely) two  
years after publication of the RFC, and not backported as patches to older  
versions. Adoption rate will probably be more like the phasing out of SSL  
v3-only servers (currently 0.88% of servers (0.97% 3 years ago), 1.04% of  
Alexa top million, 1.4% of Aleaxa top 10K, although none in Alexa top  
100), which have been going on for 15 years now, and if we just  
extrapolate based on the reduction rate and assume client vendors don't  
put any pressure on sites, it will probably take another 30 years to  
complete the phaseout.

Assuming that the Alexa list is a fair representation of which sites are  
important to most users, this does not exactly fill me with confidence  
that the posited 1% SCSV patched sites will include the ones a security  
minded user will consider important.

As for how many servers are intolerant (of SSL v3-only servers in  
parenthesis) [of Renego patched in square brackets, all servers]:

  Version intolerance TLS 1.0-TLS 1.2 : 0.7% (4.9%)[0.20%]
  Version intolerance TLS 1.3+ : 2.6% (5.4%)[1.18%]
  Extension intolerance TLS 1.0-TLS 1.2: 0.98% (19.7%)[0.29%]
  Extension or version intolerance TLS 1.0-TLS 1.2: 1.07% (19.8%)[0.41%]

  Renego patched SSL v3-only: 42%

For further reference, below is a sample of the top domains that have  
servers that are NOT patched for the renego issue as of yesterday. Keep in  
mind that my sample list includes many servers that are not the main front  
line servers; they may, for example, have patched "www", "login" and other  
frontline servers, but not other servers that the user may encounter in  
their perusal of the site, and which may handle important aspects of their  
transactions.

   Yahoo.com + national domains
   Amazon.com + national domains
   ebay.com + national domains
   linkedin.com
   microsoft.com
   mail.ru
   163.com
   fc2.com
   paypal.com
   craiglist.com
   ask.com
   apple.com
   imdb.com
   bbc.co.uk
   aol.com
   adobe.com
   rakuten.co.jp
   liverdoor.com
   netflix.com
   uol.com.br
   alibaba.com

-- 
Sincerely,
Yngve N. Pettersen

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