Subject: [COSE] Getting rid of Message Type field

From: "Jim Schaad" <[email-masked]>
Date: Mon, 5 Oct 2015 17:02:39 -0700

Carsten has several times stated that he wants to get rid of the message
type field in the current document.  I don't know that this is a viable
idea, but I do want to explore the options at this point.

Problem Statement:

It is not always possible to determine from context which if the different
COSE message structures is being used at any given point.  The message type
field exists to allow for a fixed determination in all instances.  The issue
is that one is wasting space in those cases where it is definitely known
which structure is being used.  One also needs to keep in mind that
structures may be moved from locations where the type can be determined to
locations where the type cannot be determined.

Argument #1 - Jim is wrong and the message type can always be inferred from
context.  
I don't think anyone is going to make this argument, but if they do this is
where it goes.

Various Alternatives:

1.  Leave things alone:  There is a one byte penalty per message to have the
field.  Always having it means there is never any choice about if it exists
and where it exists.

2.  Move it to a CBOR tag:  This starts out as being the same size as the
current system.  Making it optional makes it easy to tag for those cases
where it can be implicit.  The biggest issue is that this consumes
potentially precious CBOR tag number space to stay in the single digits.  If
it is a separate field as present, there are 24 unsigned integers (and
potentially can go to unsigned integers) to have a good number of both
structures and versions of structures identified.  The number of CBOR tag
numbers in the single bytes is limited as a number are already assigned.
Doing this makes the current request for a COSE tag obsolete.

3.  Make it a header parameter:  This will grow the size of the message by
one when the message type is present.  It has the nicety that the message
type can be protected (may want to think about protecting it in any event),
but it makes it harder to do a simple check of what the message type is  You
need to do a map lookup and potentially a second CBOR decode and a map
lookup to find what the message type is.  

4.  Make the message type optional:  It is easy from a typing point of view
to determine if the message type is present or not.  It is an integer and
the next item is always going to be a binary value.  It complicates the code
slightly, in some cases the code indexes the array starting at zero and in
other cases it starts at one to look for fields other than the message type.
(Either that or it just inserts a message type to make life easier.) 

5.  An option Jim has not thought of (or rejected):  Fill in if you come up
with something.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Oct 2015 02:41:10 +0200

The message-type field as it is, is useful if you do know that you are looking at a COSE structure, you just don’t know which one.
That situation is certainly possible, but it doesn’t strike me as particularly likely or the one we should design for.

A CBOR tag would be a globally unique identifier.  (You still would need to know you are looking at CBOR, but the initial bytes representing the tag actually creates a bit of a signature — in that other meaning of the word, also known as magic number.)

I would go for tags in the space between 24 and 127; this requires two bytes, but there are enough of these to allocate three of them for COSE, and the two-byte signature is more unique.

(Looking at the bytes again: by removing msg-type, we save one byte in the case that I would call the usual case, and spend two instead of one in the case where we have little context, but we gain a bit more of the signature effect in the latter case.)

Grüße, Carsten

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 6 Oct 2015 07:48:03 +0300

> lookup to find what the message type is.  

Regarding protecting the type: I think the type really should be
protected. Right now, seemingly the only reason careless
implementations[1] aren't subject to MAC vs signature confusion (a'la
multiple JOSE implementation vulernabilities) is that MAC_structure and
signature_structure have different number of elements (3 vs 4).

There's also Enc_structure, which has 2 elements. I don't know if
one could cause problems if one could mix that up with MAC_strructure
(currently can't happen because those happen to have 2 vs 3 elements),
but I would rather be careful and assume yes.

Then what's to say there won't be future new message types that have
structure types that collide with existing ones in dangerous way?

One way to make the accidential-looking separation explicit would be
to add message type indication to the structure itself (it would be
one constant byte, never appearing on the wire).

[1] Always assume there will be careless implementations. Because if
whatever has many implementations there _will_ be (this has been shown
over and over again).

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Oct 2015 13:24:51 -0700

There has been no further discussion on this topic.

Carsten has proposed that we adopt a solution to “removing” the message type field from the current structures.   His argument basically includes the statement  that, on average, the message type will be known from context at least 51% of the time in those cases where message size is a strong consideration.  For this reason going with a two byte prefix for identify the message type where not already unknown is acceptable.

I do not believe that we have any data either to support or refute this statement.  

My current intention is to implement this change in the document, along with the change to validate the message type as part of the cryptographic handling.  Are there objections?

Jim

From: Carsten Bormann [mailto:[email-masked]] 
Sent: Monday, October 05, 2015 5:41 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] Getting rid of Message Type field

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 09 Oct 2015 23:19:58 +0200

Jim Schaad wrote:
> My current intention is to implement this change in the document, along
> with the change to validate the message type as part of the
> cryptographic handling.  

I didn't say that in my original missive, but the latter one obviously
is important.
What's the general approach we'll use for mixing in extra information
(that is not in the protected-header) into the signing input?
Unless we are very careful, we'll run into canonicalization issues.

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 10 Oct 2015 13:29:53 -0700

How externally supplied data is to be integrated into the validation process is currently documented.   Please let me know if you find it a problem.  The canonicalization issue is punted to the application.

Jim

> -----Original Message-----
> Sent: Friday, October 09, 2015 2:20 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> > My current intention is to implement this change in the document,
> > along with the change to validate the message type as part of the
> > cryptographic handling.
> 
> I didn't say that in my original missive, but the latter one obviously is important.
> What's the general approach we'll use for mixing in extra information (that is
> not in the protected-header) into the signing input?

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Oct 2015 22:41:20 +0200

> How externally supplied data is to be integrated into the validation process is currently documented.   Please let me know if you find it a problem.  The canonicalization issue is punted to the app…

No problem with that, but here we are talking about our own data (a
message type, even if implicit).

Grüße, Carsten