Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

Dave Garrett <davemgarrett@gmail.com> Fri, 26 December 2014 23:58 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A91ACFB7 for <tls@ietfa.amsl.com>; Fri, 26 Dec 2014 15:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0BDQiP770Ht for <tls@ietfa.amsl.com>; Fri, 26 Dec 2014 15:58:23 -0800 (PST)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9DA1ACFB6 for <tls@ietf.org>; Fri, 26 Dec 2014 15:58:23 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id bm13so7550252qab.3 for <tls@ietf.org>; Fri, 26 Dec 2014 15:58:22 -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:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=2T0K78o2LpXlbPWFqXbqJiyEiAjg6H0BqPBvjhRUXU0=; b=bLpGELNSi+Lf1mGzJbdHeGEe11QroAjWhUeN5QN+i12FHjBk6KvCjd4zOsnbI0J7PT CmvbjEReRyneFp8FFDmj7KIjAcW/XBDfkKNdzxYO5b9czrnkl1D0wyriXT7Yuxn6CK0a 5zNqeTnQRuynutYggSMXPuvRELla0+dh+dN/GREbo2vPuPmB+W7y6l3yJ62QH7vtr9mt Xjq4Qnf6wnL8/GoyDzACwGPA9tYGPu+eXy8kd0mG2eQ21hrwEWnKUXjvFfODKpSdZjEp q85lJp80jxTdF++cgenbxco2qOp06ufBzC6xR2wU6tWZeSiR2ePE7iEi2Bx/TXaHO7ai yz9Q==
X-Received: by 10.140.95.71 with SMTP id h65mr6251575qge.92.1419638302843; Fri, 26 Dec 2014 15:58:22 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id j3sm18464617qas.19.2014.12.26.15.58.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Dec 2014 15:58:22 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Kurt Roeckx <kurt@roeckx.be>
Date: Fri, 26 Dec 2014 18:58:19 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; )
References: <201412221945.35644.davemgarrett@gmail.com> <201412261747.00959.davemgarrett@gmail.com> <20141226232625.GA7199@roeckx.be>
In-Reply-To: <20141226232625.GA7199@roeckx.be>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201412261858.20140.davemgarrett@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mHywVYvrp-NczYWki1J7r1511sk
X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft
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: Fri, 26 Dec 2014 23:58:26 -0000

On Friday, December 26, 2014 06:26:25 pm Kurt Roeckx wrote:
> Isn't it up to the implementations to decide if they still wish to
> support it?  Does it do any harm to support it other then possible
> talking to outdated software?
> 
> (It currently seems to be about 150 lines in OpenSSL, and it seem
> clear to me that it's just to support that.)

It's always possible for some implementation to have a bug in how it handles 
hellos. Having to decipher which is which is not as clean as one would hope. 
Just because it's probably being done correctly now, doesn't mean some (new) 
implementation couldn't do something bad here. If there is a problem, it's 
probably not going to be properly tested, seeing as it's an obsolete format. 
It's yet another thing to worry about.

> Even if TLS 1.3 reduces complexity, it's not suddenly going to
> make any implementation less complex.   I think it's likely going
> to make things more complex.   It's not like we're going drop
> support for the older protocols at the same time.  We'll add one
> more that is different then the others.

Well, strictly speaking, the goal is to add as little new complexity as 
possible, in total. Dropping SSL3 support is at least another drop in 
complexity, as well.

> > Refusing to connect to these old clients will also, hopefully, get some
> > of them upgraded to new ones that actually work with modern protocols.
> 
> Or prevent the adoption of the new software because it breaks
> things.

Anyone using software that old has probably already made that choice. :/

> I would also like to get rid of TLS 1.0.  It's just not realistic
> to do this at this point in time.  Only about 50% of the http
> servers support TLS 1.2 currently.

I agree. I'm certainly not in favor of an SSL2/3 style prohibition RFC, or 
anything. I'm just saying that it would be far better to attempt to put some 
pressure on them rather than just waiting around. Unfortunately, I admit that 
changing UIs to indicate HTTP as insecure, and releasing HTTP/2 and 
letsencrypt.org are prerequisites to getting serious about not tolerating out-
of-date security. An official "please stop using TLS 1.0" from the IETF is about 
the best one could hope for, at the moment. I guess we'll get that to some 
degree with:
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08


Dave