Re: [COSE] Multicast Use Case

[Göran Selander <[e-mail]>]

Hi,

Independently of the multicast use case, there is a secure communication
setting that is similar to this example which I think deserves being
considered in COSE.

What I expect to be a common setting is that the receiver has already
established a security context, including algorithm, key, sequence
number/used nonces etc. with a context identifier that is locally unique.
In this case the only information that needs to be passed in the message
is context identifier and nonce/sequence number together with ciphertext +
tag.

You may of course argue that you should use the existing COSE_encrypt
format.  But since a) the assumptions are quite different, b) the
optimizations may be significant and c) this may be a common mode of
operation, I think it actually deserves a (sub-)format of its own. If we
don’t define this in COSE, someone may be tempted to do this elsewhere.


Regards
Göran



On 2015-08-31 09:22, "Hannes Tschofenig" <[e-mail]> wrote:

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