Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?

Sean Leonard <dev+ietf@seantek.com> Wed, 24 July 2019 23:53 UTC

Return-Path: <dev+ietf@seantek.com>
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 95FB8120098 for <cbor@ietfa.amsl.com>; Wed, 24 Jul 2019 16:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Eqcjp_xzupQF for <cbor@ietfa.amsl.com>; Wed, 24 Jul 2019 16:53:19 -0700 (PDT)
Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA9F1200B1 for <cbor@ietf.org>; Wed, 24 Jul 2019 16:53:19 -0700 (PDT)
Received: from dhcp-96ed.meeting.ietf.org (dhcp-96ed.meeting.ietf.org [31.133.150.237]) (Authenticated sender: sean@seantek.org) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 36400100004; Wed, 24 Jul 2019 23:53:15 +0000 (UTC)
From: Sean Leonard <dev+ietf@seantek.com>
Message-Id: <3246C0B0-C5BF-4AC8-B99F-D9A44B780A2C@seantek.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3F06424C-2980-4745-8026-B010D44C421B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 24 Jul 2019 19:53:11 -0400
In-Reply-To: <CANh-dXm0TLShk_9DT9fKq0CR4yJMr6=zntWL8fW2tB99o0Et3Q@mail.gmail.com>
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org
To: Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org>
References: <CANh-dXkkSJUOcHcBj1JRO20ULFVNNbu1GQU-j7bR7N-FCTt3HA@mail.gmail.com> <24038E27-C30B-47F4-91E8-68C02FCAE26D@tzi.org> <CANh-dXm0TLShk_9DT9fKq0CR4yJMr6=zntWL8fW2tB99o0Et3Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/cTwhWw4J2Vd1DU5eTRHSJ8gBMtw>
Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?
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, 24 Jul 2019 23:53:23 -0000

I find round-tripping with ES6 TypedArray to be a sufficiently compelling use case, that it should stay in.

That being said, the fact that typed arrays is prompted by and mirrors ES6 TypedArrays—a non-CBOR standard—also prompts me to call for having the tags assigned in the > 255 space. If more TypedArray types are defined in that spec, it is easier to assign the tags to CBOR in a larger block of numbers.

That issue, I feel, was never actually resolved on the merits. I believe that the assignment of tags in the 1-byte space (40-255) provides less flexibility and extensibility than assigning them in the 2-byte space (256-65535).* The case in point illustrates that between draft-ietf-cbor-array-tags-00 and draft-ietf-cbor-array-tags-03, the tag 1040 got introduced seemingly came out of nowhere and broke up the nice block of numbers. Since 1040 has been introduced anyway, that is a strong indication that everything should be in the 256-65535 space.

Sean

*or they could be called 2-byte space and 3-byte space: it’s not clear if there is a consistent definition that we have been using.

> On Jul 24, 2019, at 6:17 PM, Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org>; wrote:
> 
> On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
> To make sure that we don’t create a trap for generations to fall into, a paragraph could be added to the security considerations..
> 
> That sounds like a good idea.
> 
> Jeffrey
> 
> Generally speaking, an implementation that wants to perform operations on input data will need to validate that to be appropriate for that beforehand.  The potential trap here might be that a Uint8ClampedArray might feel a lot more like a Uint8Array than other types do to each other so the validator would be misled.  So don’t do that…
> 
> Grüße, Carsten
> 
> 
> > On Jul 24, 2019, at 16:01, Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote:
> > 
> > In https://github.com/cbor-wg/array-tags/issues/6 <https://github.com/cbor-wg/array-tags/issues/6> I complained that
> > tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is
> > a property of further processing rather than the data encoded in CBOR.
> > I worried that we might introduce security issues by allowing a
> > potentially-malicious sender to decide how the recipient processes the
> > received data.
> > 
> > More abstractly, I believe this is the only tag in the document that
> > extends the CBOR generic data model.
> > 
> > I don't think the current text adequately describes when a recipient
> > should create a Uint8ClampedArray from potentially-untrusted input
> > data. But I 1) didn't object during the last call and 2) don't think
> > this is a big enough issue to try to hold up the process if other
> > folks think it's fine.
> > 
> > So, how do other folks feel about the marker for clamped uint8 arrays?
> > 
> > Thanks,
> > Jeffrey
> > 
> > _______________________________________________
> > CBOR mailing list
> > CBOR@ietf.org <mailto:CBOR@ietf.org>
> > https://www.ietf.org/mailman/listinfo/cbor <https://www.ietf.org/mailman/listinfo/cbor>
> > 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor