Re: [Cbor] Unusual map labels, dCBOR and interop

[Carsten Bormann <[e-mail]>]

Hi Orie,


On 2024-03-28, at 15:10, Orie Steele <[e-mail]> wrote:
> 
> Let me try my argument one more time, and if it doesn't land, then maybe I'm chasing ghosts.

This thought experiment makes some assumptions about what people could be doing that fall firmly into “don’t-do-that-then” [1] land with me.

[1]: http://www.catb.org/jargon/html/D/Don-t-do-that-then-.html

> Let's say you have a CWT based protocol that is supposed to implement dcbor,

CWT is not based on dCBOR, so I don’t know what that would mean.
(OK, maybe that new protocol is a variant that is *not* a CWT but otherwise similar, let’s call it NCWT.)

> and that spans multiple middle boxes.

And that is definitely a good scenario to test the above…

> The protocol starts with a coin flip to decide which serialization to use "cbor or dcbor".

After the coin flip, it would need to tell the result, e.g., by using a different media type.

> After deciding any time "cbor" is chosen, a random "dcbor incompatible data element" (such as undefined, or weird numbers) is inserted into the unprotected header by every middle box that supports "cbor" and not "dcbor".
> 
> My concern was that on the wire, the boxes will see "application/cbor", but internally they will process them as "application/dcbor+cbor”,

Well, both media types (assuming there will be a dcbor+cbor) are non-specific and therefore do not provide much of a handle to do any application processing.

> hence it is less safe for this protocol to use "application/cbor"... but it would be more safe for this protocol to use "application/dcbor+cbor".

Yes.
But it would be much better to use media types that are more specific as to the application protocol.

> I think the recommendation for such a protocol would be to define a more specific dcbor based media type, like "application/foo+cbor", 

Exactly.

> but then in the media type registration cite dcbor instead of normal cbor....

Exactly.

> I suspect that people won't read this registration and will look at "+cbor" and assume "undefined" and "weird numbers", are allowed.

But there is never an assumption that foo+cbor allows all of CBOR; we usually try to provide some CDDL or other specification that defines (and thus restricts) the application data model.
Intermediates that randomly insert data items into an application protocol they don’t understand are destructive.

> That's the argument I am trying to articulate, is this a concern? 

The usual response here would be “let’s write some text then” (e.g., for the security considerations to discuss check/use vulnerabilities).  
But if your assumption is that people don’t read, that won’t help.

Grüße, Carsten