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

Dave Garrett <> Fri, 26 December 2014 22:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE4891ACF7C for <>; Fri, 26 Dec 2014 14:47:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2qCDIWy-cL8c for <>; Fri, 26 Dec 2014 14:47:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E03C51ACF80 for <>; Fri, 26 Dec 2014 14:47:05 -0800 (PST)
Received: by with SMTP id v10so4105261qac.25 for <>; Fri, 26 Dec 2014 14:47:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=By4ZwkP6Rnp3YXpA7Ddy6mOILxgEoUcx9eHY4mjc0tQ=; b=DYH+gYwjbS5FnPcNc1dvyxxh3GupsKVQMSsHSBUAVlE4OKQp9bQB7bsFLvz0cEjZvl LSbIx1jbl7ruqNeOmtdN+Sn3ZI4wUbe2YtDYJNQsCBfN1tJZBGqHdHorfo9xf2In+0Rt xyRzxv//evja2m/oEsoRK+g7Y54hIQw/LfJK90HshkZBnNV+V5pXCVYleet0oD0SqAiQ X66sY8dluSBrx9Pa3x7tuNbdXEpnHayur3cIiYVdmBiJxqopU1aSnDs8fgRsgMi6p6Gm xSpy1+sxNKnVJw1CbfpxiS9JSsHQrV8NcP0Sdm//dJ4XvHLnXv7K9DoH3JD+dAqZQii5 CfJg==
X-Received: by with SMTP id z11mr37616748qab.17.1419634025100; Fri, 26 Dec 2014 14:47:05 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id k4sm27119397qaf.0.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Dec 2014 14:47:04 -0800 (PST)
From: Dave Garrett <>
To: Kurt Roeckx <>
Date: Fri, 26 Dec 2014 17:47:00 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; )
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800
Cc: " (" <>
Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Dec 2014 22:47:07 -0000

On Friday, December 26, 2014 01:11:39 pm Kurt Roeckx wrote:
> On the other hand if you do receive such a client hello you're
> likely talking to old software that most likely isn't support
> anymore and might have various security issues.  It might be a
> good indication of clients you prefer not to talk to.

My primary concern is that continuing to maintain official support for a 
deprecated format from an insecure protocol leaves a significant amount of 
complexity in place just to support woefully out-of-date implementations. I 
think that many people agree that one of the main goals of TLS 1.3 needs to be 
reduction of complexity. The more legacy features that are removed, the simpler 
the protocol will be, and the safer it will be to implement properly.

Refusing to connect to these old clients will also, hopefully, get some of them 
upgraded to new ones that actually work with modern protocols.

> It's saying that you should refuse a connection from a client that
> supports TLS 1.0 but set it up using a SSLv2 compatible client
> hello.  If TLS 1.0 is still acceptable, why would you refuse such
> a connection?

If there were a simple way to detect that, without having to support the old 
hello format, and reply with a simple refusal that triggered a negotiation using 
TLS, then that might be preferable. However, at some point it's just not worth 
it. You just have to cut off backwards compatibility, eventually.

Also, I'm not sure I agree that TLS 1.0 is still acceptable. Personally, I'd 
like to see an official deprecation and an attempt to force implementations to 
upgrade to at least 1.2 at some point. HTTP/2 should help here, I hope. (at 
least on the web) It would be nice to not have to panic and handle some fatal 
flaw in TLS 1.0 like had to be done for SSL 3.