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

Carsten Bormann <cabo@tzi.org> Wed, 02 October 2019 09:20 UTC

Return-Path: <cabo@tzi.org>
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 E7B1E120113; Wed, 2 Oct 2019 02:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 YepDpd_Yjrxn; Wed, 2 Oct 2019 02:20:18 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9301200FE; Wed, 2 Oct 2019 02:20:18 -0700 (PDT)
Received: from [10.159.97.60] (ewa_guest_internet_sthlm_nat2.ericsson.net [192.176.1.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46jrFr4Q1Szykx; Wed, 2 Oct 2019 11:20:16 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <156986975771.502.11307283771427797323.idtracker@ietfa.amsl.com>
Date: Wed, 2 Oct 2019 11:20:16 +0200
Cc: The IESG <iesg@ietf.org>, cbor@ietf.org, draft-ietf-cbor-array-tags@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com
X-Mao-Original-Outgoing-Id: 591700814.247027-75873898cd41bc3f0a840f7240a854ec
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4AE4B03-E8AF-41A4-BCDE-3262393674AC@tzi.org>
References: <156986975771.502.11307283771427797323.idtracker@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/StPLHTEkcrv_og9zDbLMuMSAxBs>
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: Wed, 02 Oct 2019 09:20:21 -0000

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).

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)…

> 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.

> 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

Grüße, Carsten