Re: [TLS] Deprecating SSLv3

Manuel Pégourié-Gonnard <> Tue, 11 November 2014 20:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 63BF91A701A for <>; Tue, 11 Nov 2014 12:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.397
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aXf7jDJ_nfRa for <>; Tue, 11 Nov 2014 12:28:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 967DE1A9095 for <>; Tue, 11 Nov 2014 12:28:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=XZ0gSo/pnVM2hEjDQ0jpomVaetM6MV9Sxp/9jG3vkwA=; b=CL7p7eTdkMN6nMC8OLFlKcduVVIF7LEj5fQKJOwh9J/H+mYwDWsti4wd10cct0sFMpT/vK8FFiY+hlVoCefne3U/bGW20/xkFQDUjQUdXef5+MSbrEuRAb4UhGP2dhakOwcP3gYAo5T0Qr4DTgdJQpEkhOWhVO7mZU/ogqQtMA8=;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1XoI2c-0004z4-Lt; Tue, 11 Nov 2014 21:27:55 +0100
Message-ID: <>
Date: Tue, 11 Nov 2014 21:27:58 +0100
From: Manuel Pégourié-Gonnard <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Martin Thomson <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
Subject: Re: [TLS] Deprecating SSLv3
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: Tue, 11 Nov 2014 20:28:09 -0000

On 11/11/2014 00:17, Martin Thomson wrote:
Thanks for your work on this! I'm very sympathetic to the goal, but I'm a bit
puzzled by the following statement:

                                                   Clients MUST NOT set
   a record layer version number (TLSPlaintext.version) of {03,00}.
   Clients SHOULD offer their highest supported version (that is, the
   same value that appears in ClientHello.client_version); though
   clients MAY use any value greater than or equal to the lowest version
   number they are willing to negotiate.  Servers SHOULD accept
   handshakes from clients that propose SSLv3 or higher, but MUST NOT
   negotiate SSLv3.

The underlying assumption between the first sentence seems to be that
TLSPlaintext.version somehow indicates the lowest version that the client is
willing to negotiate. The last sentence also seems to imply the server knows the
range of versions the client is willing to use (as opposed to just the highest
version), which seems to confirm that.

Is there already something in the standard that says that the client offers a
range of versions by using TLSPlaintext.version for the lower bound in addition
to ClientHello.client_version? I didn't find it, so I'm worried about
(implicitly) introducing new semantics about version negotiation in this document.

Also, I'm curious about the reason why clients SHOULD "offer" the same version
in TLSPlaintext.version as in ClientHello.client_version: first, I'm not sure
what purpose it serves. Second and more importantly, isn't there a risk of
introducing new intolerance issues? This is an actual question, if you have the
answer and it's no, I'm delighted.