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

Yoav Nir <ynir.ietf@gmail.com> Wed, 21 January 2015 09:16 UTC

Return-Path: <ynir.ietf@gmail.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 36CAD1A07BC for <tls@ietfa.amsl.com>; Wed, 21 Jan 2015 01:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 UHqRDl2XbU-7 for <tls@ietfa.amsl.com>; Wed, 21 Jan 2015 01:16:48 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD6A1A09CF for <tls@ietf.org>; Wed, 21 Jan 2015 01:16:48 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id fb4so19115421wid.2 for <tls@ietf.org>; Wed, 21 Jan 2015 01:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=p1NEPenQh5ZGflg4/EyT8Id4myjtDJdUcit+EQ+dXJk=; b=FJm8y+v4puHY5xptHIX9n5xn7vGgatMuswgLlVaCuOOskIx+dlemR3qwYnEEvYd92T jFRbhBMbvcxwK51xiRFWdH00Imr2KWh4/xwKEtQBBHSSp5nHTMY3vTqKlzSOIJp3FwIX sQuy+4sgMGaCdovOtigtWr86iDv9Vf22ozs28GJxpPvLh9RseCRqTsVjNOVxFTC0FnRX OhYAf0Nx8hRISyakAuDKVUxAubiN6UcYk2QayvjXPyFA9AHNhqY54cYP+KpHKHPB1cnl 2/eT42BfYKcZIxop/Iu6ZuIS7jHzM0swbrX2RWWPjphvcb777OF0DRD9AC9t6rEupgFp ch3g==
X-Received: by 10.194.203.234 with SMTP id kt10mr24898962wjc.88.1421831807035; Wed, 21 Jan 2015 01:16:47 -0800 (PST)
Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id vh8sm24654646wjc.12.2015.01.21.01.16.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 01:16:46 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D65E6CFA-B6CC-4A53-9548-15A51BDF32C2"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <BAY180-W1849690A1D8C42F1063DDBFF480@phx.gbl>
Date: Wed, 21 Jan 2015 11:16:43 +0200
Message-Id: <39B8BC24-D539-456F-970B-B11665B0E892@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> <>> <BAY180-W1849690A1D8C42F1063DDBFF480@phx.gbl>
To: Xiaoyin Liu <xiaoyin.l@outlook.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/oquDfT-1q2VfZtKMlFmtNsOK93w>
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 09:16:51 -0000

Thanks

In that case, I think my implementation would fail with (1.3,1.3). Since I can’t know what changes TLS 1.3 made to the record layer, I can’t be sure that I understand what I’m parsing. Perhaps those bytes that I thought were the ClientHello are actually some new fields that were added to the record header.

If the record layer version exceeds what the server supports, I think it wouldn’t be prudent to reply with anything but an alert. Many implementations treated the record layer version in the ClientHello as a minimum version number. Yes, I know this goes against a MUST requirement in appendix E.1 or RFC 5246, but as that appendix says, this is behavior that is often implemented.

Yoav

> On Jan 21, 2015, at 9:40 AM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:
> 
> 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 <mailto: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 <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