[TLS] record-level version number in ClientHello

Manuel Pégourié-Gonnard <mpg@polarssl.org> Sat, 01 November 2014 22:11 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 1EFA21A1B3B for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 15:11:10 -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 7vNKbmixOgDh for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 15:11:09 -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 D26C51A1B38 for <tls@ietf.org>; Sat, 1 Nov 2014 15:11:08 -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:To:MIME-Version:From:Date:Message-ID; bh=BGeU63QZ7Dyw68rUzYscW8OV8Cbn6Z7ickMpfy/1Kks=; b=D5/aujv6ZgmQxIBz067CR3xZ2ln3HHG26le6H86HtFLfJMFal1KalX4K+xvdfOdtw15eiP0Z3lDAORO8OfJDpmrlo7iPNP6weNeCCrV5XGZxXt8JA0TjQJTMl2cPBdBAmeXVFr4wBYqjEW8jdPeXLgM8vWGoelKk+4rWasKRMAw=;
Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Xkgsv-0006uZ-88; Sat, 01 Nov 2014 23:11:01 +0100
Message-ID: <54555A79.30803@polarssl.org>
Date: Sat, 01 Nov 2014 23:11:05 +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: c.kahlo@ageto.net, "'Yngve N. Pettersen'" <yngve@spec-work.net>, tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <op.xonuwux33dfyax@killashandra.invalid.invalid> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com>
In-Reply-To: <5455577f.e402c20a.6dee.2253@mx.google.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.161.199.191
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/2tmhTTrei8r8w806mHtN_ZzH78E
Subject: [TLS] record-level version number in ClientHello
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, 01 Nov 2014 22:11:10 -0000

[changing the subject line this it has nothing to do with RFC 7366]

On 01/11/2014 22:58, Christian Kahlo wrote:
>> IIRC, I found out that it doesn't like 03 00 as the record-level
>> version number in the ClientHello. I was able to connect by setting the
>> minimum version of my test client to TLS 1.0, which upped the record-
>> level version number of the ClientHello to 03 01.
> 
> Yes, SSLv3 is explicitly unsupported. As there is no handshake back-
> ward compatibility with SSLv3 "03 00" is forbidden at the record level.
> 
I certainly agree about not supporting SSLv3 at all, but I'm not convinced
rejecting record-level 03 00 this is the best thing to do . In practice this
mostly means rejecting clients that want to interoperate with old servers.

My interpretation of the last paragraph of RFC 5246 E.1 below

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

is life is already complicated enough for clients, and servers should help them
by accepting any half-sensible value here (it's always time to be stricter later).

Just my opinion.

Manuel.