Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

"Andreas Walz" <> Thu, 24 November 2016 07:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 241CD129555 for <>; Wed, 23 Nov 2016 23:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4fWcGVsEF3o9 for <>; Wed, 23 Nov 2016 23:38:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD58712954E for <>; Wed, 23 Nov 2016 23:38:38 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 396FC12F69E6 for <>; Thu, 24 Nov 2016 08:38:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1479973114; x= 1480837115; bh=pFugOYA21HXyLvEHQtNDHZn3lsYIDk9QUo5AHUPZOQg=; b=V NMTKzCeb7Hs1Y7RlPJBDj4ZMqCLifjO0328bo6yU9KH3WIG6TaLirmAyl73R4mB1 AVq//AXnuOyZEBLfOOFkyiHMzX6oF1Og7CQ8hDCFWleXnoPMy64u5h739jwWR/5d 6YF0snPUqfBsi39Vjt/MqrCzeAKNajRs1Y2na01Fj4=
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZCFDnra3G6qm for <>; Thu, 24 Nov 2016 08:38:34 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTPS id 8DCD412F69D8 for <>; Thu, 24 Nov 2016 08:38:34 +0100 (CET)
Received: from gw_dom-gwia2-MTA by with Novell_GroupWise; Thu, 24 Nov 2016 08:38:34 +0100
Message-Id: <>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Thu, 24 Nov 2016 08:38:32 +0100
From: Andreas Walz <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part764F15E8.0__="
Archived-At: <>
Subject: Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]
X-Mailman-Version: 2.1.17
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: Thu, 24 Nov 2016 07:38:41 -0000

>>> Eric Rescorla <> 11/23/16 2:18 PM >>>
> In general, it should ignore it. It's going to become increasingly common to 
> have this be a version you don't support given the recommendation to use
> 0301 and the ongoing deprecation of TLS 1.0. I think it would be fine to sanity
> check the major version, but I'm not sure what would be gained by requiring this. 

The one benefit of checking at least the record's major version I see is that one
preserves means for the future to signal a record format incompatible with the
current one. Otherwise, this field is given away for arbitrary and non-standardized
(ab)use ...

Thanks and Cheers,


Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany

>>> Benjamin Kaduk <> 11/10/16 5:22 PM >>>
     On 11/08/2016 06:25 PM, Martin Thomson wrote:
            On 9 November 2016 at 05:59, Brian Smith <> wrote:
                This isn't a pervasively shared goal, though. It's good to let the browsers
police things if they want, but I think a lot of implementations would
prefer to avoid doing work that isn't necessary for interop or security.
              If you permit someone to enforce it, then that is sufficient.  I don't
think that we should ever force someone to enforce these sorts of
things (as you say, sometimes strict enforcement isn't cheap or even
     Agreed.  We should probably change the text a bit, though, as right     now readers can get two different readings depending on whether they     go for a strict decode_error (or illegal_parameter?) since the     struct doesn't match the definition, or follow the "MUST be ignored     for all purposes".

 TLS mailing list