Subject: [Cose] Sizes of messages

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 May 2015 22:55:18 -0700

I have spent a couple of days looking at messages that are likely to be sent
for the world of CoRE/ACE based on the draft
https://tools.ietf.org/html/draft-selander-ace-object-security-01 and the
response on key management that I got back recently.  I have made several
assumptions in doing the computations.  I have included my spreadsheet of
the different cases so that you can look at where I had assigned bytes used.
If people have other cases where they would like to get sizes computed,
please send them to me and I can run the numbers.

Case #1 - MAC on a content using a direct key.   I am assuming, probably
without cause, that this is going to be the most common message type sent.
(It could be case #2 instead).   The details of the message that I am
looking at are:
	-  We use a one byte internal identifier for the message type
	-  We are protecting the algorithm identifier and a nonce.
	-  We are carrying no unprotected headers
	-  We are using a nonce which is one byte long - increasing the size
of the nonce would uniformly increase the size of the message for both
configurations
	-  A payload of 19 bytes is assumed and it is assumed that the
content is being carried inside of the message.
	-  The algorithm for the MAC is HMAC-SHA-256 and the tag is
truncated to 16 bytes.
	-  A key identifier of 8 bytes is used.
	-  There is no AAD field built into the message, but there may be
external AAD information passed in (i.e. carried in the message header).
	-  Assuming a single recipient and the recipient information
structure is encoded as a map w/o an array wrapper.
	-  In this case using maps takes 62 octets and using arrays takes 63
octets.

Case #2 - Encryption on a content using a direct key.  The details of the
message that I am looking at are:
	-  We use a one byte internal identifier for the message type
	-  We are protecting the algorithm identifier
	-  We are carrying no unprotected headers
	-  We are carrying an IV of 8 bytes.  This could be shortened under
some circumstances, but that would be equal in both mappings.  There is no
reason to carry it as a protected header item as CCM and GCM both
automatically include the IV value in the authenticated data computation.
	-  A payload of 19 bytes is assumed and it is assumed that the
content is being carried inside of the message.
	-  The algorithm for the encryption is AES-128-CCM-64, the tag is  8
bytes.
	-  A key identifier of 8 bytes is used.
	-  There is no AAD field built into the message, but there may be
external AAD information passed in (i.e. carried in the message header).
	-  Assuming a single recipient and the recipient information
structure is encoded as a map w/o an array wrapper.
	-  In this case using maps takes 60 octets and using arrays takes 61
octets.

Case #3 - Sign a message using an asymmetric key.  The details of the
message that I am looking at are:
	-  We use a one byte internal identifier for the message type
	-  We are protecting the algorithm identifier and the kid
	-  We are carrying no unprotected headers
	-  We are assuming that the payload it detached and not part of the
message
	-  The algorithm is ECDSA using P-256 - thus the signature value
itself is 64 bytes.
	-  In this case using maps takes 82 bytes and arrays takes 83 bytes.
If content is included, then the array will be the same size as for map.

Case #4 - Sign a message using an asymmetric key and encrypt it using a
direct key.
	- For the signature, the conditions are the same as for 	case
#3 with the exception that the content is carried in the message.
	- For the encrypt operation, the conditions are the same as for case
#2.
	- For map, the size is 145 octets, for array the size is 146 octets.

For all of the cases that I have provided above, I am using the minimal set
of fields.  If any other fields are added, for example unprotected
attributes, then the balance tips from maps to arrays as the cost to add a
field is 2 octets plus the data, whereas the cost to add a field to an array
is just the size of the data.

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 11 May 2015 08:39:31 +0200

> content is being carried inside of the message.

Just a quick comment on that one. In the world of sensor networks, the 
payload of a message will often be a sensor reading, which could be as 
small as e.g. a single floating point number or even an integer. So we 
should assume we will get a significant number of payloads in the order 
of magnitude of 2-4 bytes.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Derek Atkins <[email-masked]>
Date: Mon, 11 May 2015 11:28:13 -0400

Ludwig Seitz <[email-masked]> writes:

> should assume we will get a significant number of payloads in the
> order of magnitude of 2-4 bytes.

In my experience we've found that it's better to combine a bunch of
sensor readings together, specifically because they are so small that
the added overhead of separating them because unwieldly.

> /Ludwig

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Mon, 11 May 2015 11:35:10 -0400

Jim,

> please send them to me and I can run the numbers.

Thank you for this work!

> Case #1 - MAC on a content using a direct key.   I am assuming, probably
[snip]
> Case #2 - Encryption on a content using a direct key.  The details of the
[snip]
> Case #3 - Sign a message using an asymmetric key.  The details of the
[snip]
> Case #4 - Sign a message using an asymmetric key and encrypt it using a
[snip]
> is just the size of the data.

So in the minimal case it definitely sounds like a map provides a tiny
edge in the data size over an array.  In my use case (#3 above) I do
expect that I'll have the payload included as opposed to detacted, so in
my case the sizes are equivalent.

However I feel that a map also enables future extensions easier than an
array, in particular if you have future optional features.  Not that I
can currently think of what extensions might occur, but I'm not
omniscient either ;)

Thanks,

-derek

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 May 2015 13:37:08 -0700

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Sunday, May 10, 2015 11:40 PM
> To: [email-masked]
> Subject: Re: [Cose] Sizes of messages
> 
small
> as e.g. a single floating point number or even an integer. So we should
> assume we will get a significant number of payloads in the order of
> magnitude of 2-4 bytes.
> 
> /Ludwig

I kind of just chose an arbitrary number, this does not change what the
overhead of sending a message is   The break points on message sizes from
the size of CBOR are at 24/25 bytes (tag and length goes from 1 to 2 bytes)
and at 255/267 bytes (tag and length from 2 bytes to 3 bytes).  The next
break would be at 2^24 bytes.   

If you care about the ratio of content to overhead then knowing an exact
message size matters otherwise it probably doesn't.

If you sizes are really that small, what are you doing about dealing with
replay - are you assuming that is all covered in the security overhead
rather than in your base message size?

Jim

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 12 May 2015 09:52:57 +0200

> message size matters otherwise it probably doesn't.

No argument about that, plus as Derek pointed out there are cases where 
combining several of these values into one message makes sense.

> rather than in your base message size?

Yes, I'm one of the co-authors of draft-selander, so for replay 
protection we are suggesting to apply the procedure described in section 
5.3 (using sequence numbers + key identifier).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Göran Selander <[email-masked]>
Date: Tue, 12 May 2015 11:21:32 +0000

>is just the size of the data.

I’m missing an encrypt-then-sign case: Encryption of content using a
direct key and sign it using an asymmetric key.

Here is one use case:

Constrained nodes publish and multiple nodes subscribe to the
publications. The pub-sub broker is not trusted with the plain text
publications of its publishers, but only publishes its associated
publishers publications. The publications are therefore encrypted with a
symmetric key shared among the subscribers, and further signed with the
private key of the publisher. With access to the authentic key of the
publisher, the subscribers and the pub-sub broker can verify the
publication comes from the publisher.

I hope it would be possible in this case to get a message size closer to
case #3 rather than case #4?

Göran

---

From: Derek Atkins <[email-masked]>
Date: Tue, 12 May 2015 14:22:57 -0400

[snip]
[snip]
[snip]
> direct key and sign it using an asymmetric key.

This is the same as case #4 except that the ordering/processes are reversed.

[snip]
> case #3 rather than case #4?

Nope, your use case is exactly the same as case #4 and would be exactly
the same size (assuming you're using a stream-like cipher and not a
block-like cipher).  The difference is only whether you encrypt the sign
or sign then encrypt.  The number of bytes required to hold the
signature and encryption metadata doesn't change and cannot be combined
just because you swap the order.

-derek

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 12 May 2015 12:37:55 -0700

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Tuesday, May 12, 2015 11:23 AM
> To: Göran Selander
> Cc: Jim Schaad; [email-masked]
> >>Case #2 - Encryption on a content using a direct key.  The details of
> >>the message that I am looking at are:
> [snip]
> >>Case #4 - Sign a message using an asymmetric key and encrypt it using
> >>a direct key.
> >>For all of the cases that I have provided above, I am using the
> >>minimal set of fields.  If any other fields are added, for example
> >>unprotected attributes, then the balance tips from maps to arrays as
> >>the cost to add a field is 2 octets plus the data, whereas the cost to
> >>add a field to an array is just the size of the data.
> >>
> >
> > I hope it would be possible in this case to get a message size closer
> > to case #3 rather than case #4?
> 
> Nope, your use case is exactly the same as case #4 and would be exactly the
> same size (assuming you're using a stream-like cipher and not a block-like
> cipher).  The difference is only whether you encrypt the sign or sign then
> encrypt.  The number of bytes required to hold the signature and encryption
> metadata doesn't change and cannot be combined just because you swap
> the order.
> 
> > Göran

What Derek said, this is basically re-arranging the deck chairs on the titanic, does not make much difference.

In terms of the use case that you gave (and Derek snipped).  I would want to know who is doing the group key distribution mechanism to the system.   I would normally expect this to be the same entity as is doing the re-distribution of the message so I don't know that I think this is a very realistic use case.  That entity is going to know all of the keys that belong to everybody anyway.

Jim

---

From: Göran Selander <[email-masked]>
Date: Tue, 12 May 2015 20:26:09 +0000

On 2015-05-12 21:37, "Jim Schaad" <[email-masked]> wrote:

>
>In terms of the use case that you gave (and Derek snipped).  I would want
>to know who is doing the group key distribution mechanism to the system.
> I would normally expect this to be the same entity as is doing the
>re-distribution of the message so I don't know that I think this is a
>very realistic use case.  That entity is going to know all of the keys
>that belong to everybody anyway.

The key distribution would be done by an Authorization Server (see e.g.
Section 2.3 of https://datatracker.ietf.org/doc/draft-gerdes-ace-actors)
whereas the pub-sub broker would be an intermediate node between the
endpoints of figure 7 (compare section 3.1). The functions are distinct,
the former is a trusted third party, the latter a forwarding function, and
they may well be performed by different entities.

Göran