Re: [TLS] Prohibiting SSL 3.0

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 29 October 2014 11:52 UTC

Return-Path: <mpg@polarssl.org>
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 609161A002C for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 04:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 xwdn8vSUVfAi for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 04:52:00 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2071A000E for <tls@ietf.org>; Wed, 29 Oct 2014 04:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=VOO0aFqoa5qm/MyFX/Y7bXpa7qrmRU/v+BYJVQfJwrY=; b=iRniZ2aqvSDLmAN907kuGBKfUC3sbJrfzJ4gb4h2kFN6FM3s49+BeiuqxxY7rCy25NNavw8SZXcKelIVhuTUARbF87d5nFLvwMP+uHdynfvwzCQBeFBN4qeol30GWooQirQzStEgh1OBsfhCJdlC3EPvKm7OeI0774FWnqE8YeU=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XjRmw-0001GS-Qi; Wed, 29 Oct 2014 12:51:52 +0100
Message-ID: <5450D4D3.40603@polarssl.org>
Date: Wed, 29 Oct 2014 12:51:47 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>, Hubert Kario <hkario@redhat.com>
References: <BLU177-W4981235CC3AA2325B8CC01C39F0@phx.gbl> <877fzka1bf.fsf@mid.deneb.enyo.de> <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com> <87tx2np1i5.fsf@mid.deneb.enyo.de> <5450CFC1.2020308@polarssl.org>
In-Reply-To: <5450CFC1.2020308@polarssl.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vXi9-Uqi0wORTcTcwB34JUimeCY
Cc: tls@ietf.org
Subject: Re: [TLS] Prohibiting SSL 3.0
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, 29 Oct 2014 11:52:01 -0000

On 29/10/2014 12:30, Manuel Pégourié-Gonnard wrote:
> On 29/10/2014 12:18, Florian Weimer wrote:
>> * Hubert Kario:
>>
>>> Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatible 
>>> client hello with server support being stated as MAY. Similarly, the value for 
>>> SSL 3.0 for record layer in client hello is mentioned as the backwards 
>>> compatible option with no mention of recommendation against it.
>>>
>>> I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively for 
>>> SSLv2 and SSLv3, at the very least) is not entirely out of scope...
>>
>> I think the SSLv2 compatible client hello is unrelated to the protocol
>> version advertised by the client, but I might be mistaken about that.
>>
> Unless I'm mistaken, there is no point for a client to send a SSLv2 compatible
> ClientHello unless the client is prepared to actually negotiate SSLv2. If think
> if fair to say that client MUST NOT do that.
> 
> OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
> server will never negotiate SSLv2. So I guess the MAY here is ok.
> 
... which is exactly what RFC 6176 says (thanks Bodo for mentioning it, I
totally forgot about it). So maybe the TLS 1.3 draft should just be updated to
refer to RFC 6176 here?

Manuel.