[COSE] Message size considerations

[Francesca Palombini <[e-mail]>]

Hi,


We have re-calculated the message sizes for the different use cases that are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column "overhead cose-msg-08" of table below).

We think that the COSE_Encrypt format is well designed for applications which have tight requirements on message size, the overhead being of the order of 10 bytes (excluding tag and necessary header parameters of size which depends on application). We don't see any reason why we should get twice the overhead if we MAC or Sign a message instead.

In this mail we propose some optimizations that mainly have an impact on the other formats, see column "overhead with mod" in the table below.

In order to decrease the message size overhead we propose to add 2 new message types: one for single signature (1) (in our use case we don't need multiple signatures), and one for MAC with no recipient (2).

The rest of the mail is discussing the optimizations and our proposal. We thought to start this discussion here in the mailing list, but we could also add our requests in the issue tracker if it is preferred.



Reading up on the discussion about COSE structure for single signer [2], [3], we could not find any "closure" to that discussion, and like to revisit the topic again.

Analogously to the COSE_Encrypted structure, we consider that all information necessary for the cryptographic operations is pre-established between the endpoints. The Context Identifier sent protected in the message is enough to identify the security context and all the parameters necessary for crypto computations (alg, key, etc) previously set up in the endpoints. Because of that, we don't need to send the signer/recipient info in the message, and we suggest to optimize the COSE structure for this use case.


We propose the following modifications:

a. remove the alg parameter from the message sent: since all information is pre-established in the nodes' security context, we don't need to send the alg in the message. (saves 2B)

b. for the new single-signature structure (1), we only need to send the btstr 'signature', we can remove the 'signatures' and 'COSE_signature' structure. The Context Identifier and the Sequence Number are sent in the COSE_Sign protected header. (saves 5B)

c. remove the recipient structure from the new MAC structure (2). (saves 8B)

d. as for b, for the COSE_Encrypt with counter signature use case, we propose to give the choice to use the whole COSE_Signature structure or only the btstr 'signature' as 'counter signature'.
If we only send the btstr 'signature' (our use case), we assume that the alg for counter signature is also defined in the security context. (saves 8B)


Even if these improvements may seem small, please note that in some cases the difference is half the total overhead, which is not insignificant.


Table: Message overhead

+--------------+-------------+----------+------------+
|      COSE    |  overhead   | overhead | difference |
|  Structure   | cose-msg-08 | with mod |            |
+--------------+-------------+----------+------------+
| COSE_Sign    |     18 B    |   11 B   |     7 B    |
+--------------+-------------+----------+------------+
| COSE_Encrypt |     11 B    |    9 B   |     2 B    |
+--------------+-------------+----------+------------+
| COSE_Mac     |     20 B    |   10 B   |    10 B    |
+--------------+-------------+----------+------------+
| COSE_Encrypt |     20 B    |   12 B   |     8 B    |
| +counter sig |             |          |            |
+--------------+-------------+----------+------------+


As a summary, this is how we would modify the COSE_Message structures in order to optimize the message size, and how many bytes we would save from each modification:

COSE_Sign: [protected, unprotected, payload, [[ protected, unprotected, signature]]]
Bytes removed:                             -2B(b) -1B(b)     -4B(a,b)

COSE_Sign single signature (new type): [protected, unprotected, payload, signature]


COSE_Mac: [protected, unprotected, payload, tag, [[ protected, unprotected, ciphertext]]]
Bytes removed:           -2B(a)               -2B(c) -1B(c)     -4B(a,c)    -1B(c)

COSE_Mac no recipient (new type): [protected, unprotected, payload, tag]


COSE_Encrypt: [protected, unprotected, ciphertext]
Bytes removed:   -2B(a)

COSE_Encrypt: [protected, unprotected, ciphertext]


COSE_Encrypt with counter signature: [protected, {7:[protected, unprotected, signature], ...}, ciphertext]
Bytes removed:                          -2B(a)  -1B(d) -1B(d)    -4B(a,d)

COSE_Encrypt with counter signature mod: [protected, {7: signature, ...}, ciphertext]


To meet Jim's arguments against b. and c. in his previous message [2] (most recent message I could find about this topic):

"4.  There is currently a very clear cut rule about things only being used at the layer they are placed in.  This means that currently key identifiers are never placed in the same layer as a content key algorithm.  This would be broken by the proposal put forth.  I worry that once this is done, there will be more items than kid that will migrate between layers.  One of the things that I never liked in the JOSE proposals what the number of places that one needed to look for the various control fields.  Currently in COSE this is limited to two places.  If we introduce the possibility of cross layer contamination then this number might grow in the future to deal with implementation faults.
One of the way that these faults might develop is for designers to say - I think that this should be authenticated, and thus will put it at the wrong layer to ensure that it is.  Either without thinking about the question - should it be authenticated, or a different algorithm be required so that authentication is possible."

We suggest to have one layer only for this specific use case where we don't use this recipient/signer structure anyway, in new structures adapted for this use case. We are not proposing to change the current structures, which would be used when recipient/signer structures are necessary.

"5.  Code size is going to be very different if two different methods of dealing with structure needs to be supported.  It is currently being assumed that direct key is going to be the major use case in a number of situations. If this is not the case then current proposals do not help the situation any.  If it is true that more than one method of key management needs to be
supported then the code size is going to grow because of the need to support an additional way that key management is going to be done."

In our particular application of COSE, we don't need to support use cases with recipient/signer structures. The creation of different msg types as we suggest should make implementation easier.

Francesca


[1] https://tools.ietf.org/html/draft-selander-ace-object-security-03

[2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY

[3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc