[COSE] Multicast Use Case

[Hannes Tschofenig <[e-mail]>]

Hi Jim, Brian, all,

I am trying to compare the work on multicast security done by Sandeed &
co against an application layer solution using CBOR/COSE.

The DTLS multicast includes the following relevant components:
- Epoch: 2 Byte
- Sender ID: 1 Byte
- Sequence Number: 5 Byte

The combination of epoch, sender id and sequence number are used as a
nonce for the cipher and the use of the sender id ensures that no member
of the group accidentally selects values that will cause re-use.

The 1 byte sender id is chosen small to reflect the expected size of a
group in the professional lighting environment, as explained in the DTLS
multicast document.

Ciphersuite related information includes:
- Encrypted Content (variable length)
- MAC (variable length)

Content Type, Version and Length are DTLS-specific aspects that cannot
be removed without re-design of the record layer.

Data based on Figure 4 of
http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08.txt.

Since there is no sequence number defined in COSE I put the epoch and
the sequence number together into the nonce field.

Here is the commented version of the COSE message I came up with:

[
     2, // Encrypted COSE message
     {
       1: 10, // Algorithm - AES-CCM-16-64-128
       5: h'89f52fa' // 7-byte nonce
     },
     h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0',
      // encrypted payload.
     [
       [
         h'',
         {
           1: -6, // Direct use of CEK
           4: h'01' // Key ID - 0x01
         },
         h''
       ]
     ]
   ]

According to cbor.me the resulting COSE encoding has 59 bytes whereby 28
bytes are purely used for message encryption.  This means that there is
31 bytes overhead with COSE compared to 12 bytes [= 8 for Epoch +
Sequence Number + Sender ID, 3 bytes for Content Type and Version fields].

Ciao
Hannes