Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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" To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part764F15E8.0__=" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 07:38:41 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part764F15E8.0__= Content-Type: multipart/alternative; boundary="=__Part764F15E8.1__=" --=__Part764F15E8.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> Eric Rescorla 11/23/16 2:18 PM >>> > In general, it should ignore it. It's going to become increasingly = common to=20 > 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.=20 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 ... =20 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 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 desirable). =20 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". =20 -Ben =20 =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 =20 --=__Part764F15E8.1__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0Abody p =0A{ =0A margin: 0px; =0A}=0A
>>> Eric Rescorla&= nbsp;<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


--=__Part764F15E8.1__=-- --=__Part764F15E8.0__=--