IETF Logo Mail Archive

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

Fabrice <fabrice.gautier@gmail.com> Sat, 27 December 2014 22:59 UTC

Return-Path: <fabrice.gautier@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 0CA941AC3C2 for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 14:59:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=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 ihQTjMIYSgSY for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 14:59:06 -0800 (PST)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6376F1AC3BC for <tls@ietf.org>; Sat, 27 Dec 2014 14:59:06 -0800 (PST)
Received: by mail-pd0-f171.google.com with SMTP id y13so14903165pdi.2 for <tls@ietf.org>; Sat, 27 Dec 2014 14:59:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mSgzj2jkg63Ajzyiqu49J+55l931sRl0dl5DpXMwABU=; b=lxBUGJlHnQHUF7ML4tkpiIfWtnVTlXEcL3rljrYgkAyh2XOKErsKEW202XBJVRGnTn +2qI7EAtE5n0ufnAkRe0NgHHrUC8JbCfwUFBcS1DvT4ruX16cs/WmkyVB3ghOtH/sH0l gU9jtcQjGGEmVZaYid2YTIeybs6jMAGnUhQVi2e/u2qXETzJWtcWwdMM/t1pk4OqDN86 jeOUO57Rt3D92UCH3EjY1M60d/t3SFUwHT8V3037KldzI/f1ZN29jZSvnqSZmqmpTqMk fd0nMfXo6vR19ubkoSNXM0mCejWlvqsrn5GxX2jEp9uLw20/fCtUWQf7z1+QjM6wT8wr MI7w==
X-Received: by 10.68.239.70 with SMTP id vq6mr77260654pbc.110.1419721145667; Sat, 27 Dec 2014 14:59:05 -0800 (PST)
Received: from [172.16.42.7] (c-73-15-172-83.hsd1.ca.comcast.net. [73.15.172.83]) by mx.google.com with ESMTPSA id i7sm18692772pdp.3.2014.12.27.14.59.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Dec 2014 14:59:04 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (12E165)
In-Reply-To: <549F2D90.5030305@hauke-m.de>
Date: Sat, 27 Dec 2014 14:59:02 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <32B9010C-C209-4D55-9AEA-5BC3EBE738A3@gmail.com>
References: <201412221945.35644.davemgarrett@gmail.com> <F07340BA-F182-470C-AF90-C85A973075B9@gmail.com> <549F2D90.5030305@hauke-m.de>
To: Hauke Mehrtens <hauke@hauke-m.de>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jcpkEJysPK2K7Q7FjUG2PhBPlrY
Cc: Dave Garrett <davemgarrett@gmail.com>, "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: Sat, 27 Dec 2014 22:59:08 -0000

> On Dec 27, 2014, at 14:07, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> 
> 
> 
> On 12/24/2014 07:40 AM, Yoav Nir wrote:
>>> 
>>> There's no reason to maintain any backwards support here just for Internet 
>>> Explorer 2.0 on Windows 3.1.
>> 
>> I’m not objecting to the change, but I am objecting to the hyperbole. The issue is with Internet Explorer 6 on Windows XP, which still exists, but more importantly, a lot of web service clients running on top of Windows XP use the same SCHANNEL library as IE would use, so they issue a SSLv2 ClientHello. Despite Microsoft’s best efforts, there is still a substantial but diminishing install base of XP.
>> 
>> It’s fine for us to break compatibility with these clients, but let’s not pretend it’s some ancient technology that doesn’t exist in the market anymore.
>> 
>> Yoav
> 
> In addition the Oracle Java Runtime Environment in Version 6 uses a SSL
> v2 compatible ClientHello in the default settings. It supports SSL v3
> and TLS 1.0. In Java JRE 7 a SSLv3 ClientHello is used by default.
> 
> I think a TLS 1.3 Client must not send a SSLv2 ClientHello, but a server
> should understand it.

openssl s_client, is also using a SSLv2 hello unless the -no_ssl2 option is used. (At least in the 0.9.8 version shipped on OSX, other may comment if this is still true on other platforms and in more recents OpenSSL version)

s_client is often used in scripts and test harness and there is no easy way to disable that behavior globally short of recompiling.

In my mind, the point of explicitly forbidding v2 hellos on the server side is to:
- First eventually kill all remaining clients that's still speak v2 by default. 
- Once those clients are gone this should finish killing all remaining ssl2 servers.

Also, the complexity of implementing the SSLv2 record parsing on the server side for servers that only do TLS is real. Isn't that the origin of the bug that caused server to hang on client hello with specific size? The one that motivated the writing of https://tools.ietf.org/html/draft-agl-tls-padding-03 ?

I think implementors will be happy to remove that bug prone piece of code from their stacks, eventually.

-- Fabrice. 


> Hauke
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email