[TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]
"Andreas Walz" <andreas.walz@hs-offenburg.de> Wed, 23 November 2016 11:39 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 0E47F129CE5 for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 03:39:43 -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 gKzygCsE7iNA for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 03:39:40 -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 3761912996D for <tls@ietf.org>; Wed, 23 Nov 2016 03:39:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id DC69D12E932B for <tls@ietf.org>; Wed, 23 Nov 2016 12:39:37 +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=1479901176; x= 1480765177; bh=WtwUf2J5GnB8FO2lTICM8VV6f1X5Phtfynjdd0OopgQ=; b=C GlX8QjpNgZZ+jEbrjxjBTwnGKLiVcTeJKXNvPzGNKpylr+L2OK8jafCxtsJo6hns gNJiRkhDX2Dg/sJDr2ucWAY3A2XX/FfcKJRcBzi/fl//A0KBCamPrr/Q9cNF6uoJ ECIP0iJlYZQ88rB5ON5WUylMnNC1izRbRDaUrWo60Y=
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 Hu8tbMvxHDzx for <tls@ietf.org>; Wed, 23 Nov 2016 12:39:36 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id AC2E212E9326 for <tls@ietf.org>; Wed, 23 Nov 2016 12:39:36 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Wed, 23 Nov 2016 12:39:36 +0100
Message-Id: <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Wed, 23 Nov 2016 12:39:35 +0100
From: Andreas Walz <andreas.walz@hs-offenburg.de>
To: tls@ietf.org
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>
In-Reply-To: <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9DA4FDE7.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/btYVXpVYD2SrvcalHuiVtDYs-50>
Subject: [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: Wed, 23 Nov 2016 11:39:43 -0000
Dear all, bringing up this thread again .... In the course of studying the way TLS implementations treat the "version" (or "legacy_record_version") field in the record header, we were wondering (please excuse if we missed some arguments here from past discussions): (1) What is an implementation (in particular when receiving the first bytes over a new connection) supposed to do if the record's version field signals a protocol version the implementation does not support? I understand that, at this stage, enforcing a specific value (e.g. 0x0301 according to the TLSv1.3 draft) is detrimental to interoperability. However, if that field bears any meaning (in either TLSv1.3 or previous versions), what is it? I would expect this field is supposed to allow signaling a potentially non-backward compatible record format (inauspiciously interfering with a receiver disregarding the record version). Provided this field isn't treated as an enum, what about checking/enforcing at least the major version as BoringSSL does (as far as I know)? In any case, I would propose to be very clear about this in the text (my sense was that there is some work in progress, but I couldn't find anything). In implementations (<TLSv1.3), we found all kinds of interpretations. (2) What is an implementation (up to TLSv1.2, as the TLSv1.3 spec is rather clear about that) supposed to use for the record's protocol version field before a version has been agreed upon (e.g. when sending an alert after receiving an unparsable ClientHello)? My best guess would be to set it to the lowest (TLS) protocol version that uses the same record format (probably 0x0301). However, we observe several servers which, in such cases, answer with an alert with weird record protocol version values, e.g. 0x0000.] 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] 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