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

Bodo Moeller <bmoeller@acm.org> Wed, 21 January 2015 17:09 UTC

Return-Path: <SRS0=t9k+=CI=acm.org=bmoeller@srs.kundenserver.de>
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 84AC41A1B28 for <tls@ietfa.amsl.com>; Wed, 21 Jan 2015 09:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 WiTCCDnsz19D for <tls@ietfa.amsl.com>; Wed, 21 Jan 2015 09:09:05 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD64E1A1AFA for <tls@ietf.org>; Wed, 21 Jan 2015 09:09:04 -0800 (PST)
Received: from mail-la0-f47.google.com ([209.85.215.47]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0Mcixh-1YVEXn3W3V-00HwN4 for <tls@ietf.org>; Wed, 21 Jan 2015 18:09:02 +0100
Received: by mail-la0-f47.google.com with SMTP id hz20so8115623lab.6 for <tls@ietf.org>; Wed, 21 Jan 2015 09:09:02 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.150.98 with SMTP id uh2mr9295202lbb.92.1421860142147; Wed, 21 Jan 2015 09:09:02 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Wed, 21 Jan 2015 09:09:01 -0800 (PST)
In-Reply-To: <BAY405-EAS137B89901008DF6DB9FA280FF480@phx.gbl>
References: <BAY405-EAS137B89901008DF6DB9FA280FF480@phx.gbl>
Date: Wed, 21 Jan 2015 18:09:01 +0100
Message-ID: <CADMpkcJT42xZ_9JJpzfDQk2g4DhXDN44imTeP3SusvfZn3fv7A@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b34329cb17357050d2c9c38"
X-Provags-ID: V03:K0:BZAz22X4MiA5fSaItW+gcbHLANz7AGzVgjixHDieEGh+iBN2rIJ fJdsAQLTDyVZHqfx3sEin5mwIV6t/HnVJ0AxoZqVrU7AGXwlcrHTZhdLvGPRVzc4BcWGFO9 wbXzIgf/92Ob9CFsEcIaWgmrpHpeatPGb6kWTvOBZGK2r0r07o4qVBa4BUj4hD4GTxeUjfl cirLqagVErBVM6kbN0iyA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MFxYKNQq9aZNDLKxihXu-ZwnC48>
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 17:09:06 -0000

Xiaoyin Liu <xiaoyin.l@outlook.com>:

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.
>>
>>

> I must admit I don't quite understand what the argument here is (sorry),
>> but in any case let me point out this:
>> If even just a *single* high-value site that you, personally, use does
>> support the SCSV, you'll benefit from the SCSV (provided that you're using
>> a browser that
>>
>

> My argument is that suppose 50% websites support fallback SCSV now, 48%
> websites do not support SCSV but are version tolerant, and less than 2% are
> version intolerant. Is it worth to sacrifice the security of the 48%, to
> make the 2% "just work"?


I see, thank you.

draft-ietf-tls-downgrade-scsv-03 doesn't ask that clients do downgrades at
all, it just helps them avoid security pitfalls *if* they choose to.
Historically, many browsers have done this (and still do) and while I'll be
glad if this practice can be stopped, it is still an issue for now (and if
we manage to get rid of it, it might become an issue again).  A couple of
years ago I thought it would go away, but that hasn't happened yet, and
I've seen browsers that initially tried to get along without implementing
the downgrade dance add it.  Even in the yet-to-be-released Firefox version
that disables the downgrade dance by default, there'll still be a
configurable setting for those who think they'll need it -- and the SCSV
will improve their security.


I also want to point out that disabling RC4 and deprecating SHA-1
> certificates will break some sites as well. Why could browsers afford that,
> but insist on doing downgrade dance?


I hope they'll do *all* of this. The point is that the SCSV improves your
security before you have completed such a transition -- or indeed before
you even know about a concrete vulnerability that might convince you to
disable a legacy protocol.

Bodo