[TLS] SSL 2 CLIENT-HELLO backwards compatibility compromise

Dave Garrett <davemgarrett@gmail.com> Thu, 12 February 2015 22:27 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 944591A1A0B for <tls@ietfa.amsl.com>; Thu, 12 Feb 2015 14:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Pk-x6DcTq4sg for <tls@ietfa.amsl.com>; Thu, 12 Feb 2015 14:27:48 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070E61A0430 for <tls@ietf.org>; Thu, 12 Feb 2015 14:27:27 -0800 (PST)
Received: by mail-qg0-f51.google.com with SMTP id z60so10451060qgd.10 for <tls@ietf.org>; Thu, 12 Feb 2015 14:27:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:user-agent:mime-version:to:cc:content-type :content-transfer-encoding:message-id; bh=tFdhUAxs8Nv0s84E0/FV9PUJDqW7AjPCGnKFoFxbr5Q=; b=uCGVx2wTo06ATKKnjZBHupr9ZhwCH8ZX6CFTCsIhFPAXxQh6H3Ko83TYMrhRpdWPbg gYdZlDFlC6Y30GJ7eyb7NiXhZLAjNCzK03Nmx+j06d7omw4f4MWrtJfKnitlFhWUaimh fHUIJjQ6LJ4kgj/wn9KJFJCMibIjGHgiwG+vZhir5Jp4zEaThwWSdLy1lIk79TB/WxH3 wmBFsc9CFIkeBuSCVqZsJGOWO5aUu60HerVGsLi3HGKfgjVfTC2rx2+jYPJc4GHHGjCe sLHH4jNcMEBaZHrX3C4lqRIej7mXMlIdFAjkvoXbUiZKTp6E+hLVDFRl2YCNUvj2iCi9 WgWg==
X-Received: by with SMTP id h81mr785276qhc.35.1423780046292; Thu, 12 Feb 2015 14:27:26 -0800 (PST)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by mx.google.com with ESMTPSA id y2sm5292619qae.47.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Feb 2015 14:27:25 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
Date: Thu, 12 Feb 2015 17:27:24 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
To: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201502121727.24768.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wTJYx5WbqEjO0Iz1gx5capPom-8>
Cc: Florian Weimer <fweimer@redhat.com>
Subject: [TLS] SSL 2 CLIENT-HELLO backwards compatibility compromise
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, 12 Feb 2015 22:27:50 -0000

The previous consensus is in the draft now, so resuming discussion on
what to do with the SSL 2 CLIENT-HELLO format as was planned.


I'd like to say there are roughly 3 options on how to deal with SSL 2
CLIENT-HELLO backwards compatibility in TLS 1.3 implementations.
(to reiterate, we're talking about the format defined in
https://tools.ietf.org/html/rfc5246#appendix-E.2 )

Option #0) Current draft
v2 format MUST NOT be sent ever
v2 format MUST NOT be used at all for TLS 1.3+
v2 format NOT RECOMMENDED to accept for TLS 1.0-1.2

Option #1) Ditch the format that has been deprecated for 20 years
v2 format MUST NOT be sent or accepted for any reason

Option #2) Restrict to TLS 1.0
v2 format MUST NOT be sent ever
v2 format MUST NOT be used at all for TLS 1.1+
v2 format NOT RECOMMENDED to accept for TLS 1.0

The reason I frame the choices like this is that the TLS 1.0 case was of primary discussion. The TLS 1.2 case was brought up, but seems to have way less justification. Recent discussion also suggested setting TLS 1.1 as allowed and TLS 1.2 as not, however I think focusing only on the primary case of TLS 1.0 could be much better.

There has been some limited discussion on how to proceed with deprecating TLS 1.0, and TLS 1.1 has been said to be sufficiently improved as such to not necessarily deprecate it with it. With option #2, once TLS 1.0 is dropped, then for remaining supported TLS versions the situation is the same as option #1; the v2 format is completely prohibited after that point. I think option #2 is a reasonable compromise if enough people are sadly against option #1.