[TLS] SCSV versioning

🔓Dan Wing <dwing@cisco.com> Thu, 26 February 2015 20:34 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5F7321A8729 for <tls@ietfa.amsl.com>; Thu, 26 Feb 2015 12:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v4DbRn2QO1I0 for <tls@ietfa.amsl.com>; Thu, 26 Feb 2015 12:34:46 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779501A1BE7 for <tls@ietf.org>; Thu, 26 Feb 2015 12:34:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1546; q=dns/txt; s=iport; t=1424982886; x=1426192486; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=7NXaySA9zaWyw7gEYjtda4X+O9Zw+uFCS2Ul9mjRUls=; b=MwCUQ0jR1gdsDkSQOzvL5ZiZ2VhkA8+RYtEVHWSqxj0kroAOx5IhSPr8 2fxaf/Fx0Eykba3wyq7ftbd7gDb0ivKUdcD6C+BfP8WXX3NLENvTl4ln5 HFsRaxsORztrQpLLEcRj5ddQpHhDY4BDsO1RDWh4SGtnATerrFyB2v88g c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208";a="399452875"
Received: from rcdn-core-7.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2015 20:34:46 +0000
Received: from rtp-vpn6-659.cisco.com (rtp-vpn6-659.cisco.com []) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1QKYfOk018522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Thu, 26 Feb 2015 20:34:44 GMT
From: 🔓Dan Wing <dwing@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com>
Date: Thu, 26 Feb 2015 12:34:44 -0800
To: tls@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AJEC3rF5Y_LHBqeU30n4O2ICOJk>
Subject: [TLS] SCSV versioning
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: Thu, 26 Feb 2015 20:34:48 -0000

I recently became aware that Microsoft IE won't implement SCSV.  Near as I can tell, this is the main concern, but it is not terribly detailed about the concern:


> One of the developers pointed out that the TLS_FALLBACK_SCSV feature has a significant downside-- because it doesn't convey any specific version information, it becomes a general "never fall back" signal. The problem is that such signals are too broad; fallbacks were only ever introduced because servers often use TLS stacks with implementation bugs. Any "don't fallback" signal sent by such a server will be very bad for compat.
> Now, the counterargument is that servers should just implement TLS properly and update when new versions are released and/or bugs are found, but there's strong precedent showing that this just doesn't happen. IE's decade long "DocumentMode/CompatibilityView" fiasco comes from the fact that there was a single "StandardsMode" flag that the majority of pages had opted-into without actually being standards compliant.

Has this concern been discussed in the working group?  Should we resolve this?  (I think a resolution might be along the lines of "I have previously tried 1.2 and 1.1", but really depends on one's interpretation of the 'significant downside' concern that an IE developer has.)

Yes, I know SCSV has finished WG review and IESG review.