[TLS] consensus on backwards compatibility changes

Dave Garrett <davemgarrett@gmail.com> Tue, 30 December 2014 10:03 UTC

Return-Path: <davemgarrett@gmail.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 C22981A006F for <tls@ietfa.amsl.com>; Tue, 30 Dec 2014 02:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cPGp6vKeLdlM for <tls@ietfa.amsl.com>; Tue, 30 Dec 2014 02:03:06 -0800 (PST)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384D41A0041 for <tls@ietf.org>; Tue, 30 Dec 2014 02:03:06 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id x3so10113690qcv.8 for <tls@ietf.org>; Tue, 30 Dec 2014 02:03:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=b7Wj1yC3oQsgvlfaUWsttIAOpp3Rsev9Tg9FlEaNCq8=; b=PMaZJ6Baa0aTLiLuw+vcYzT7LGYvPAxRC5bZQxE4dR3UK2LPJHaBGdJdkF8hto3pKt nuSvfKxH4cr4k6BogGNTZNDvNtOEAGW/rzdWZER3L0Nwbrh0t9sZFe8yUMZLHXUgPsie Ot1Lp3YUGXZc/CKDwbYcI+erMcHsirJRS2G1qd7YQAoaYN3ZFZDmuNNU9Mb6LWlo7dsU GMowno7wdAi0bxy6lf5yTtCb+J0TyjpLqetpv0CnNZp4OjyWYf6qGmU5fFTSgeZL+eGT LJIJ8Y7lASLERd8xxjDYXCUSUMKo152nEHUJF2BBGvp/d5EnoQ9/nAeZUPZda1oQ/4VS nAJA==
X-Received: by with SMTP id e61mr91324059qga.13.1419933785287; Tue, 30 Dec 2014 02:03:05 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. []) by mx.google.com with ESMTPSA id y11sm27318231qaw.42.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 02:03:04 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Date: Tue, 30 Dec 2014 05:03:03 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201412300503.03923.davemgarrett@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SEdUwHGbsxNoCGkkvR61YfsOGpw
Subject: [TLS] consensus on backwards compatibility changes
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, 30 Dec 2014 10:03:08 -0000

Per Brian's suggestion, I've split the topic of full prohibition of SSL v2 
CLIENT-HELLO usage into its own issue, as there is clearly no consensus on this 
yet. It would be really nice if some real-world stats on how much this is 
actually used could be provided. (I think continued acceptance of it is 
illegitimate, but hard data is harder to argue with)

Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely

I have heard notable support for this, including Eric, but I do concede there 
might be too much desire for infinite backwards compatibility to reach consensus. 
I'm still hopeful we can come to an agreement that two decades is a sufficient 
deprecation period. :/

I have two PRs for the backwards compatibility section.

The first has all SSL backwards compatibility changes. In addition to RFC 6176 
SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin's 
suggestion (based on the current I-D). The v2 hello documentation is cut out, 
but seeing as it's only valid for prior versions, prior RFCs can be referenced 
if needed.

PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation

The second PR has more general backwards compatibility section improvements, 
prohibition of RC4 (also based on its current I-D), and Brian's ClientHello 
version freeze proposal. Currently, I have the ClientHello version listed as a 
"MUST", but I leave for the possibility that a "SHOULD" might be appropriate if 
other tactics for dealing with buggy servers should continue to be permitted. 
Feedback from Microsoft, Oracle, or anyone else implementing alternate 
workarounds here would be greatly appreciated.

PR #107 revise backwards compatibility & fix ClientHello version

Note that the SSL3 & RC4 language based on current drafts is of course 
contingent on those being passed successfully, though this is generally 

Both PRs update the Informative References as needed, which I've hopefully done