Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-array-tags-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 03 October 2019 20:06 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B25F12082F; Thu, 3 Oct 2019 13:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MyhscizZr2Nt; Thu, 3 Oct 2019 13:06:55 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42411202DD; Thu, 3 Oct 2019 13:06:54 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x93K6lbK015617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Oct 2019 16:06:50 -0400
Date: Thu, 3 Oct 2019 13:06:47 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Carsten Bormann <cabo@tzi.org>
Cc: The IESG <iesg@ietf.org>, cbor@ietf.org, draft-ietf-cbor-array-tags@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com
Message-ID: <20191003200647.GZ6424@kduck.mit.edu>
References: <156986975771.502.11307283771427797323.idtracker@ietfa.amsl.com> <B4AE4B03-E8AF-41A4-BCDE-3262393674AC@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B4AE4B03-E8AF-41A4-BCDE-3262393674AC@tzi.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/x3Sv0szwyfoQ5NU4ihbMl250x-8>
Subject: Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-array-tags-07: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 20:06:59 -0000

On Wed, Oct 02, 2019 at 11:20:16AM +0200, Carsten Bormann wrote:
> On Sep 30, 2019, at 20:55, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-cbor-array-tags-07: No Objection
> > […]
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Section 3.1.2
> > 
> > I don't think we can get away with defining column-major order
> > implicitly by example and comparison to row-major order.  This is
> > particularly poingiant given that we do not limit ourselves to
> > two-dimensional arrays.
> 
> The text does say:
> 
> Data Item:
> : as with tag 40, except that the data in the second array consists of
>   consecutive values where the first dimension is considered contiguous
>   (column-major order).

Huh, I seem to have not read that part the first time around.

> Should we also say that the intermediate dimensions are handled in the same order?  
> We don’t say that for row-major, but we could add it there, too, e.g. by providing a multi-dimensional example.  We could also reference (a specific version of) the Wikipedia article (https://en.wikipedia.org/wiki/Row-_and_column-major_order)…

We probably should say how the intermediate dimensions are handled, for
both cases, yes.  Or just a reference would probably be enough, too.

> > Section 7
> > 
> > I'm not sure that I understand the scenariao described by "an attacker
> > might substitute a Uint8ClampedArray" and how an application would get
> > unexpected processing semantics, but the general sentiment it indicates of
> > "applications need to verify any expectations they have" seems important
> > to cover.
> 
> The observation is that if the attacker gets to choose aspects of a data structure that is then ingested into and used within the soft belly of the application, this can give the attacker some leverage to influence the processing in an unintended way.  This is already true when the attacker can substitute an array for a hash (dictionary, map, object), but this is reasonably well known.  Uint8ClampedArray is the same in principle, but might be surprising as it is more likely to be unfamiliar to people just expecting (and validating) the presence of an array.

That's basically what I already had in mind (that still felt vague), but I
don't think there's a need to go into further discussion on it.

> > Section 8.2
> > 
> > I couldn't find a document to go with [TypedArray]; the one
> > promising-looking search result ended up just redirecting me to
> > [TypedArrayES6].
> 
> Right.  Roman's and your comment made me search a bit more thoroughly, and we now have an archive.org link; please see https://github.com/cbor-wg/array-tags/commit/3e85dd9a4fcf5b54923506a802502cc289ff7314

Thanks!

-Ben
>