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

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 24 Jul 2019 16:01:35 -0400

In 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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Jul 2019 16:40:58 -0400

To make sure that we don’t create a trap for generations to fall into, a paragraph could be added to the security considerations.

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=[email-masked]> wrote:
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 24 Jul 2019 18:17:46 -0400

On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann <[email-masked]> 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
>
>

---

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Jul 2019 19:53:11 -0400

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=[email-masked]> wrote:
> 
> On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann <[email-masked] <mailto:[email-masked]>> 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..
> 
> > On Jul 24, 2019, at 16:01, Jeffrey Yasskin <jyasskin=[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > In https://github.com/cbor-wg/array-tags/issues/6 <https://github.com/cbor-wg/array-tags/issues/6> I complained that
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/cbor <https://www.ietf.org/mailman/listinfo/cbor>
> > 
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 00:50:41 -0400

On Jul 24, 2019, at 19:53, Sean Leonard <[email-masked]> wrote:
> having the tags assigned

Too late, they already are assigned.

(If you think this shouldn’t have happened, please consider the WG’s current stance on changing the IANA considerations on 1+1 tags away from specification required.)

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Thu, 25 Jul 2019 16:17:43 -0400

> On Jul 25, 2019, at 12:50 AM, Carsten Bormann <[email-masked]> wrote:
> 

Recognizing the lateness of the comment, and that they have already been assigned, I will not pursue it further—it’s fine.

This thread raises an interesting point, namely, using CBOR tags to identify the type of object in protocol that exists elsewhere in an object oriented system, such as in other standards or other implementations. “Uint8ClampedArray” does not exist in JSON, but it exists in JavaScript/ES6 (which is both a standard and is backed by multiple conforming implementations.) I think this is a good design pattern and should be liberally employed with more CBOR tag use.

Sean

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 25 Jul 2019 16:36:40 -0400

> This thread raises an interesting point, namely, using CBOR tags to identify the type of object in protocol that exists elsewhere in an object oriented system, such as in other standards or other i…

I think that's a good description of the disagreement. I remain
uncomfortable with having a serialization format describe behaviors
that the data had or should have when it was or is loaded into a
program. The serialization should instead describe the meaning of the
data. That will correlate with the types of objects that store the
data inside a program, but it shouldn't directly determine the types.

That said, it seems unlikely that web platform uses of CBOR will use
tags, so this doesn't affect me enough to make me care that much.

Jeffrey

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 22:06:30 -0400

On Jul 25, 2019, at 16:36, Jeffrey Yasskin <[email-masked]> wrote:
> I remain
> program.

I don’t know how to avoid that.  If the input is an array, in most generic decoders I get an array to work from.  If the input is instead a map, I get a map (or a JavaScript object); that has quite different behavior.  So the supplier of the input already has a lot of control over the data structures that are input to my system.  Uint8ClampedArray just adds a slight twist to that as it might look too much like a Uint8Array.
None of this relieves an application of validating its input — with a standard serialization format and a robust generic decoder, this can now simply be done on a higher level.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 26 Jul 2019 10:08:11 -0400

Chairs:

We are expecting that Carsten will provide a pull request with the suggested Security Considerations changes to deal with this issue:

As Individual: 
See below.

-----Original Message-----
From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
Sent: Thursday, July 25, 2019 10:07 PM
To: Jeffrey Yasskin <[email-masked]>
Cc: [email-masked]; Sean Leonard <[email-masked]>
Subject: Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?

[JLS]  In many respects I kind of agree with Carsten on this.   When I look at this I have a hard time distinguishing between this case and some of the other cases where similar rules are also being required.  For example, if you tag something as UTF-8 or as MIME, the sender is controlling how both the generic decoder and the application are supposed to handle this information.   If I created a tag which defined a subset of UTF-8 then this would be even more true.   For my application both Uint8ClampedArray and Uint8Array would be placed in the same data structure type as I don't have a native type for clamped arrays.  There are then rules on how I manipulate the data.  The same is true for the subset of UTF-8.  This is going to be put into a native format for my machine - maybe UTF16 since that is the native C# data type - but there are still rules on what can be done with the data and how it can be changed.  The application is not permitted to place items in the string which do not match the legal subset of strings allowed.

Jim

Grüße, Carsten

---

From: Sean Solberg <[email-masked]>
Date: Fri, 26 Jul 2019 09:25:14 -0500

Isn't the whole purpose of the tag mechanism there to provide a way for the
sender to tell the receiver more specifically what type the data actually
is?   IE) regular expression instead of just a string,  URI instead of just
a string,  Uint8ClampedArray instead of just a Uint8Array.    Even though
the concept of a Uint8ClampedArray is mostly a javaScript thing as most
other languages naturally are "clamping" bytes to the 0 to 255 range
(because of the definition of a byte), one of the golden rules I always to
try to follow is to preserve "type" as much as possible.

IMHO, the lack of good data typing is one of the reasons we have problems
with JSON.  Having mechanisms to explicitly communicate data type from
sender to receiver is one of the areas where CBOR shines.  Frankly, I don't
see it as any more of a security issue than any other data type tagging in
CBOR.  In all cases, all receivers should be coded to properly handle what
data types it needs to deal with and also properly handle any situation
where it receives a tag that it isn't coded to explicitly handle.

..Sean Solberg

On Thu, Jul 25, 2019 at 9:06 PM Carsten Bormann <[email-masked]> wrote:

> I don’t know how to avoid that.  If the input is an array, in most generic
> decoders I get an array to work from.  If the input is instead a map, I get
> a map (or a JavaScript object); that has quite different behavior.  So the
> supplier of the input already has a lot of control over the data structures
> that are input to my system.  Uint8ClampedArray just adds a slight twist to
> that as it might look too much like a Uint8Array.
> None of this relieves an application of validating its input — with a
> standard serialization format and a robust generic decoder, this can now
> simply be done on a higher level.
>
> Grüße, Carsten
>