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

"Andreas Walz" <andreas.walz@hs-offenburg.de> Thu, 24 November 2016 07:38 UTC

Return-Path: <andreas.walz@hs-offenburg.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241CD129555 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 23:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de
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 4fWcGVsEF3o9 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 23:38:39 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD58712954E for <tls@ietf.org>; Wed, 23 Nov 2016 23:38:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 396FC12F69E6 for <tls@ietf.org>; Thu, 24 Nov 2016 08:38:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; 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 hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCFDnra3G6qm for <tls@ietf.org>; Thu, 24 Nov 2016 08:38:34 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 8DCD412F69D8 for <tls@ietf.org>; Thu, 24 Nov 2016 08:38:34 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Thu, 24 Nov 2016 08:38:34 +0100
Message-Id: <5836A708020000AC001214A4@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Thu, 24 Nov 2016 08:38:32 +0100
From: "Andreas Walz" <andreas.walz@hs-offenburg.de>
To: <ekr@rtfm.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <CABcZeBOsN+_gUUb=HoUsoPOTBgANedT5Y5O+pAGXn0qTYjq1jg@mail.gmail.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> <CABcZeBMg_QjHQf3b1mJcuDtCH1o2Gpv=YDdDPkAu5GwEhVaCfg@mail.gmail.com> <c83f4ada-f3e7-12f5-aedd-f41ff5e80665@akamai.com> <CAF8qwaC2oRqqHAeWRoGm24ZmDe0YAR6xgoA6NWNx59bV+dAOJw@mail.gmail.com> <CAFewVt7oBausHM9E83nvzOh1DRCB4f4d92t2X8EmN-CzFU41OQ@mail.gmail.com> <CABkgnnXgOJBThg66ZzXSk4vFqL8XKK3w0KGWZci=vWiLXoQ9Hw@mail.gmail.com> <CAFewVt54F6HuNqdGV0ztWvMiOSreqLmaU+VUQD9EPZkGT5=O2A@mail.gmail.com> <CABkgnnXc8MWA7HCPYCDhKXyF1G3ORxd_0yAvN+gWUBcgs5-36g@mail.gmail.com> <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de> <CABcZeBNMmdM8YqNc0tOxgoWQFXBZvSopudFTQGkvqV7qkzM6tw@mail.gmail.com>
In-Reply-To: <CABcZeBNMmdM8YqNc0tOxgoWQFXBZvSopudFTQGkvqV7qkzM6tw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part764F15E8.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BGmH-Z2Ipx9XCexP2kR-0Erl3CI>
Cc: tls@ietf.org
Subject: Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 24 Nov 2016 07:38:41 -0000

>>> Eric Rescorla <ekr@rtfm.com>; 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,
Andi

___________________________________

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





>>> Benjamin Kaduk <bkaduk@akamai.com>; 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 <brian@briansmith.org>; 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
desirable).
          
     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".
     
     -Ben
     

 
_______________________________________________
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls