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
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz