Subject: [COSE] Message size considerations

From: Francesca Palombini <[email-masked]>
Date: Tue, 8 Dec 2015 15:00:12 +0000

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

---

From: Justin Richer <[email-masked]>
Date: Tue, 8 Dec 2015 10:28:24 -0500

(As an individual)

I agree with this approach very strongly. Not only are the size differences considerable, the simplicity of the structures is very compelling. 

Looking back through the list, a lot of the early comparisons of size difference between the current COSE draft’s approach were with the JOSE “JSON Encoded” structures, which have multiple recipients and all kinds of other buts. In my view this was always a false comparison, like comparing the efficacy of a new painkiller with the efficacy of shooting yourself in the *other* foot. Yes, it’s going to be better, but nobody would choose that! What we saw with JOSE was that the simple “compact format” versions were the only ones really ever used in practice. If you look at what’s been implemented in the real world, you’ll find that the “JSON Encoded” structures with multiple recipients and all kinds of flexibility were simply not used, and continue to not be used. The vast majority of JOSE libraries don’t even bother to implement them. That really should tell us something.

And quite frankly, if the compact forms were desired in the JOSE world, I can’t see why they’re not even *more* desired in the more compact world of COSE. What we have in COSE right now is overly complicated and over generalized, and this proposed modification cuts all that fat.

Flexibility can feel wonderful to build into a system, but its attendant complexities can get in the way of that same system being actually useful to people.

 — Justin (not your chair at the moment)

> On Dec 8, 2015, at 10:00 AM, Francesca Palombini <[email-masked]> wrote:
> 
> 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).
>  
> 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.
>  
> 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’.
> COSE_Encrypt with counter signature: [protected, {7:[protected, unprotected, signature], …}, ciphertext]
> COSE_Encrypt with counter signature mod: [protected, {7: signature, …}, ciphertext]
>  
>  
> [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 <https://tools.ietf.org/html/draft-selander-ace-object-security-03>
>  
> [2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY <https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY>
>  
> [3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc <https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc>
>  
>  
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Dec 2015 15:58:09 +0000

Thanks Francesca.  I likewise agree with your approach, as I know do a number of others.  Open issue #10<https://github.com/cose-wg/cose-issues/issues/10> also asks for simplifications along these lines.  As you can see referenced in that issue, Göran Selander made a similar request in his presentation “ACE/CORE requirements on COSE<https://www.ietf.org/proceedings/93/slides/slides-93-cose-6.pdf>” in Prague.  Hopefully the editors will address this issue along the lines that you suggest soon.

                                                          -- Mike

From: COSE [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, December 8, 2015 7:28 AM
To: Francesca Palombini <[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] Message size considerations

(As an individual)

On Dec 8, 2015, at 10:00 AM, Francesca Palombini <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Table: Message overhead

Francesca

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 8 Dec 2015 23:02:18 -0800

Putting this in CDDL would be helpful

From: COSE [mailto:[email-masked]] On Behalf Of Francesca Palombini
Sent: Tuesday, December 08, 2015 7:00 AM
To: [email-masked]
Subject: [COSE] Message size considerations

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.

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)

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

| +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]]]

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)

 

Bytes removed:   -2B(a)

 

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Dec 2015 16:28:43 +0100

Francesca, I like your proposal.
Thanks for bringing it up.

Ciao
Hannes

On 12/08/2015 04:00 PM, Francesca Palombini wrote:
> 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).
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> 
>  
> 
>  
> 
>  
> 
> [3], we could not find any "closure" to that discussion, and like to
> revisit the topic again.
> 
>  
> 
> 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.
> 
>  
> 
>  
> 
> 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)
> 
>  
> 
> structure. The Context Identifier and the Sequence Number are sent in
> the COSE_Sign protected header. (saves 5B)
> 
>  
> 
> 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
> 
>  
> 
> order to optimize the message size, and how many bytes we would save
> from each modification:
> 
>  
> 
> 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.
> 
>  
> 
> 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
> 
>  
> 
>  
>

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 15 Dec 2015 13:09:53 +0000

Thank you all for your feedback.

I come a bit late for the Mac structure (as you Jim have already started with that), but here is the CDDL / text change in the draft that we were aiming at with our modifications:

a. section 3.1 : alg "This parameter MUST be present at each level of a signed, encrypted or authenticated message." We would like the alg to be optional.

b.
Add a COSE_Sign0 structure

COSE_Sign0 = [
   Headers,
   payload : bstr / nil,
   signature : bstr
]

(I guess this is what Mike meant with "equivalent no-recipient signature version" in  cose-wg/cose-spec#112<https://github.com/cose-wg/cose-spec/pull/112> )

c.
Add a COSE_Mac0 structure (already addressed in  cose-wg/cose-spec#112<https://github.com/cose-wg/cose-spec/pull/112>)

COSE_Mac0 = [
   Headers,
   payload: bstr / nil,
   tag: bstr
]

(editorial comment: there is one comma that should not be there after tag: bstr line 1417)

d.
Modify Table 1 section 3.1 to give a choice between COSE_signature and bstr as

  Table 1: Common Header Parameters

| counter  | 7     | COSE_signatur |                | CBOR encoded  |
| signatur |       | e / bstr      |                | signature     |
| e        |       |               |                | structure /   |
|          |       |               |                | signature     |
|          |       |               |                | value         |

I may have missed other places, but you get the idea.

Francesca

From: Jim Schaad [mailto:[email-masked]]
Sent: den 9 december 2015 08:02
To: Francesca Palombini; [email-masked]
Subject: RE: [COSE] Message size considerations

From: COSE [mailto:[email-masked]] On Behalf Of Francesca Palombini
Sent: Tuesday, December 08, 2015 7:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [COSE] Message size considerations

Hi,

Table: Message overhead

Francesca