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

[Benjamin Kaduk <[e-mail]>]

On Wed, Oct 02, 2019 at 11:20:16AM +0200, Carsten Bormann wrote:
> On Sep 30, 2019, at 20:55, Benjamin Kaduk via Datatracker <[e-mail]> 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
>