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

Florian Weimer <fweimer@redhat.com> Wed, 11 February 2015 13:12 UTC

Return-Path: <fweimer@redhat.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 4BFB61A886A for <tls@ietfa.amsl.com>; Wed, 11 Feb 2015 05:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LaUSR6XOX1yT for <tls@ietfa.amsl.com>; Wed, 11 Feb 2015 05:12:56 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987601A0163 for <tls@ietf.org>; Wed, 11 Feb 2015 05:12:56 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDCtUr027129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Wed, 11 Feb 2015 08:12:55 -0500
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDCsci028631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <tls@ietf.org>; Wed, 11 Feb 2015 08:12:55 -0500
Message-ID: <54DB5555.6070207@redhat.com>
Date: Wed, 11 Feb 2015 14:12:53 +0100
From: Florian Weimer <fweimer@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tls@ietf.org
References: <201412221945.35644.davemgarrett@gmail.com>, <F07340BA-F182-470C-AF90-C85A973075B9@gmail.com> <BLU177-W5178CCC10BAEA4CE3A78FBC3540@phx.gbl>
In-Reply-To: <BLU177-W5178CCC10BAEA4CE3A78FBC3540@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ay34fBJx4hvJc0DFITiCPedrGA4>
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: Wed, 11 Feb 2015 13:12:58 -0000

On 12/24/2014 08:02 AM, Yuhong Bao 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.
>>
> If needed, one suggestion would be to cap the old SSLv2 ClientHello to TLS 1.2.

At least make it TLS 1.1 instead.  With TLS 1.2, the SSLv2 ClientHello
cannot include the signature algorithms extension, so SHA-1 is used
instead of the concatenation of MD5 and SHA-1, and this usually not what
is wanted.

-- 
Florian Weimer / Red Hat Product Security