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

"Yngve N. Pettersen" <yngve@spec-work.net> Sun, 09 February 2014 16:41 UTC

Return-Path: <yngve@spec-work.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E371A0184 for <tls@ietfa.amsl.com>; Sun, 9 Feb 2014 08:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfdZeXl7bCxm for <tls@ietfa.amsl.com>; Sun, 9 Feb 2014 08:41:04 -0800 (PST)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id B2A661A0144 for <tls@ietf.org>; Sun, 9 Feb 2014 08:41:03 -0800 (PST)
Received: from 157.168.202.84.customer.cdi.no ([84.202.168.157]:65470 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1WCXRG-0006fN-FP; Sun, 09 Feb 2014 17:41:02 +0100
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: Bodo Moeller <bmoeller@acm.org>
References: <CABcZeBP_-MUonYYsxgz2ZdokiEDVhx4mYq1a4BMayuGbbxb2Gg@mail.gmail.com> <op.xabk33wdhf8200@lessa.lan> <CADMpkcK8Bz5V0vxj2grPgqH2ptmm80fM6MJb+B2fqNbhuF8ztw@mail.gmail.com>
Date: Sun, 09 Feb 2014 17:40:53 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.xa0wmfsg3dfyax@killashandra.invalid.invalid>
In-Reply-To: <CADMpkcK8Bz5V0vxj2grPgqH2ptmm80fM6MJb+B2fqNbhuF8ztw@mail.gmail.com>
User-Agent: Opera Mail/12.16 (Win32)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Feb 2014 16:41:07 -0000

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 <bmoeller@acm.org> 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/