Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

Xiaoyin Liu <xiaoyin.l@outlook.com> Wed, 21 January 2015 07:40 UTC

Return-Path: <xiaoyin.l@outlook.com>
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 EA5D31A038C for <tls@ietfa.amsl.com>; Tue, 20 Jan 2015 23:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level:
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 aB56J5QQLkRg for <tls@ietfa.amsl.com>; Tue, 20 Jan 2015 23:40:48 -0800 (PST)
Received: from BAY004-OMC1S16.hotmail.com (bay004-omc1s16.hotmail.com [65.54.190.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1B61A0389 for <tls@ietf.org>; Tue, 20 Jan 2015 23:40:48 -0800 (PST)
Received: from BAY180-W18 ([65.54.190.60]) by BAY004-OMC1S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 20 Jan 2015 23:40:48 -0800
X-TMN: [oVqs5zPvvizFHUIcLA+DlzeyWIYYhRV+]
X-Originating-Email: [xiaoyin.l@outlook.com]
Message-ID: <BAY180-W1849690A1D8C42F1063DDBFF480@phx.gbl>
Content-Type: multipart/alternative; boundary="_8df3fa31-ba8f-42a2-b677-d78856816866_"
From: Xiaoyin Liu <xiaoyin.l@outlook.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Wed, 21 Jan 2015 02:40:48 -0500
Importance: Normal
In-Reply-To: <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <, > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <,> <CAFewVt6LRafnJN_L=xVeiAxNcpSB+8vPYzquPfjXsduudyj+QQ@mail.gmail.com> <BAY180-W688DE2930CB7F231E60989FF480@phx.gbl>, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Jan 2015 07:40:48.0349 (UTC) FILETIME=[92AFC0D0:01D0354D]
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ME5zAtIUngYIKuALvi65G6mawBE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
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: Wed, 21 Jan 2015 07:40:51 -0000

Hi, Yoav, Thanks for your reply! Here is my answer: What do you mean by tolerance here? Since no servers at all support TLS 1.3, they have to break this kind of connection. Does it count as tolerance if they issue the proper alert?            A: I count a server tolerant to TLS 1.3 if and only if it replies a ServerHello handshake message with its version being TLS 1.2 or lower. Sending fatal alert (such as handshake failure, decode error, and protocol version) is not considered as tolerance. By the way, I wonder what's the proper alert here, since RFC 5246 Appendix E.1 requires "if a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server".
 Does tolerance here and below means the same thing as above? In other words, do they count as tolerant if they break the connection, or only if they respond in TLS 1.2, 1.1, or 1.0 ?          A: Yes, all of the "tolerance" means the same thing: only if they respond in TLS 1.2, 1.1, 1.0 or SSL 3.0.  Best, Xiaoyin
 Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
From: ynir.ietf@gmail.com
Date: Wed, 21 Jan 2015 08:47:15 +0200
CC: tls@ietf.org
To: xiaoyin.l@outlook.com

Hi, Xiaoyin
Thank you for the effort. I have one question. See below
On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:Hi,
 
I just finished a scan of Alexa top 1 million websites to test for TLS version intolerance. I hope this information can be useful in the discussion of downgrade SCSV.
 
For each site, I made at most four attempts with the following order to fallback:
(TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS 1.0, TLS 1.0)
where the first is TLS record layer version, and the second is Client Hello version.
 
Here is the result:
(1) Number of sites scanned: 1,000,001
(2) Number of DNS Error: 45,402
(3) Number of sites that refuse TCP connection on port 443 (RST, timeout): 289,334
(4) Number of sites that fail sending ServerHello in all 4 attempts: 238,846
(5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%)

What do you mean by tolerance here? Since no servers at all support TLS 1.3, they have to break this kind of connection. Does it count as tolerance if they issue the proper alert?
(6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)

Does tolerance here and below means the same thing as above? In other words, do they count as tolerant if they break the connection, or only if they respond in TLS 1.2, 1.1, or 1.0 ?
(7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%)
(8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a lower record layer version does improve compatibility a lot. An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate certificates nor check the integrity of handshakes. I closed the connection immediately after receiving ServerHello.
 
If my data is accurate, I am against making downgrade SCSV a proposed standard, and I believe browsers should stop insecure fallback. At least, the percentage of TLS 1.2 intolerant sites is low enough. 
I think you will find that browser vendors may not consider this low enough. 
For TLS 1.3, I think maybe browser vendors can announce a deadline, after which fallback to TLS 1.2 will no longer be accepted? Or simply break them? Both are reasonable to me.
OpenSSL has been version tolerant forever. As has Microsoft’s SChannel. I’m not sure, but I think the Java library is as well. The people running these servers are using some exotic technology, and it’s not clear they know how to upgrade them.
 Also I want to point out that if even as few as 1.6% sites won't upgrade their servers, can we count on most of the rest 98% supporting SCSV?

This is a strong argument, especially if we could obtain a list of high-value sites in the sense that the data on them is high-value. Sites like Facebook, banking, shops, email providers, dating sites, and check those. 
Yoav