IETF Logo Mail Archive

Re: [TLS] Prohibiting SSL 3.0

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 29 October 2014 11:30 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 DC3E01A000D for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 04:30:15 -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 p9JajMcoL663 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 04:30:13 -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 BB4C81A000B for <tls@ietf.org>; Wed, 29 Oct 2014 04:30:13 -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=V+JyH7gi5Dg7FO4LkLjr4iI5jevl07zbwBZXDQRxtkY=; b=ODW+FBkUGYFY6Odph9zgeNwgv84L2CLYwEC3WN93R+wd6EuwBP6oYv2y4cJNuHtv11JNNjxJYXfuucwULbnKJ/FlIDDZKAitGIpvOpgyYWkMTIe00vpj0LHUU9SxMociABpQNSaSdrH2uiSwVchiLOpoEsxxrIb35u+mIQ5cEAs=;
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 1XjRS1-0001Ea-Kb; Wed, 29 Oct 2014 12:30:05 +0100
Message-ID: <5450CFC1.2020308@polarssl.org>
Date: Wed, 29 Oct 2014 12:30:09 +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>
In-Reply-To: <87tx2np1i5.fsf@mid.deneb.enyo.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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/NUph6hNnnhMbb3VL8ndZurkCzrg
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:30:16 -0000

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.

Manuel.

v2.23.0 | Report a Bug | By Email