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

Yuhong Bao <yuhongbao_386@hotmail.com> Tue, 16 December 2014 09:58 UTC

Return-Path: <yuhongbao_386@hotmail.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 734071A1A6F for <tls@ietfa.amsl.com>; Tue, 16 Dec 2014 01:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YUf4XH52yGjb for <tls@ietfa.amsl.com>; Tue, 16 Dec 2014 01:58:08 -0800 (PST)
Received: from BLU004-OMC3S17.hotmail.com (blu004-omc3s17.hotmail.com [65.55.116.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF941A1A6E for <tls@ietf.org>; Tue, 16 Dec 2014 01:58:08 -0800 (PST)
Received: from BLU177-W34 ([65.55.116.74]) by BLU004-OMC3S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 16 Dec 2014 01:58:06 -0800
X-TMN: [jai7K6gRJI8A1wB0ady8pbD0B57p/D8I]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: <BLU177-W3476B95E8D0A4F05D1C319C36C0@phx.gbl>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: Bodo Moeller <bmoeller@acm.org>, "tls@ietf.org" <tls@ietf.org>
Date: Tue, 16 Dec 2014 01:58:06 -0800
Importance: Normal
In-Reply-To: <CADMpkcKKyd9hUjDHief5o=Vu5SXzUSmWbROzMFz5gkn-UJ7qEQ@mail.gmail.com>
References: <20141215141627.11153.69398.idtracker@ietfa.amsl.com>, <20141215214116.159171B085@ld9781.wdf.sap.corp>, <CADMpkcKKyd9hUjDHief5o=Vu5SXzUSmWbROzMFz5gkn-UJ7qEQ@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Dec 2014 09:58:06.0756 (UTC) FILETIME=[CA49E640:01D01916]
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QBdoJukdflij4XMeeeT_Vhcyb8g
Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt
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: Tue, 16 Dec 2014 09:58:09 -0000

> Martin Rex <mrex@sap.com<mailto:mrex@sap.com>>: 
>  
> > 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. 
>  
> 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) 
>  
> 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 

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