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

Yuhong Bao <yuhongbao_386@hotmail.com> Fri, 16 January 2015 20:05 UTC

Return-Path: <yuhongbao_386@hotmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EB11B2B06; Fri, 16 Jan 2015 12:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level:
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 5QCwS3m6Sf5o; Fri, 16 Jan 2015 12:05:08 -0800 (PST)
Received: from BLU004-OMC1S34.hotmail.com (blu004-omc1s34.hotmail.com [65.55.116.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482A61ACE3D; Fri, 16 Jan 2015 12:05:08 -0800 (PST)
Received: from BLU177-W27 ([65.55.116.8]) by BLU004-OMC1S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 16 Jan 2015 12:05:07 -0800
X-TMN: [BMAwHbPGwJBSHXznzbynbjBjUkfoqHp8]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: <BLU177-W27326CC964968EABAFED09C34F0@phx.gbl>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: Hanno Böck <hanno@hboeck.de>, "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
Date: Fri, 16 Jan 2015 12:05:07 -0800
Importance: Normal
In-Reply-To: <20150116210327.61046788@pc>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com>, <20150116210327.61046788@pc>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Jan 2015 20:05:07.0584 (UTC) FILETIME=[B9997800:01D031C7]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ixthovx_LX2Ck489XLMDbuUogiw>
X-Mailman-Approved-At: Tue, 20 Jan 2015 08:03:30 -0800
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jan 2015 20:05:17 -0000

This does not mean that every browser will do it.

----------------------------------------
Date: Fri, 16 Jan 2015 21:03:27 +0100
From: hanno@hboeck.de
To: tls@ietf.org
CC: ietf@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


Recently Mozilla has disabled the now so-called protocol dance, which
makes adding another workaround (SCSV) pretty much obsolete:
https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c7

And a few days ago mozilla dev Brian Smith tweetet this:
"Fx experiment to disable non-secure TLS version fallback is going even
better than expected. Starting to feel silly for delaying it so long."
https://twitter.com/BRIAN_____/status/555138042428526593

I think this adds further evidence that adding another workaround layer
(SCSV) is the wrong thing to do. Instead browsers should just stop
doing weird things with protocols that compromise security and drop
the protocol dance completely.

(By the way: Has anyone thought what happens when people implement TLS
hardware that is version intolerant to versions> 1.2 and at the same
time send SCSV in the handshake? I'm pretty sure that at some point
some hardware will appear that does exactly that. Will we need another
SCSV standard for every TLS version then?)

--
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls