Re: [COSE] Multicast Use Case

Hi Goran,
I agree with what you are saying. At least in the Multicast use case, we are able to use locally unique context information (which could be sent out during the key distribution phase) to establish a context that would allow the identification of the algorithm.
Abhinav
________________________________________
From: COSE [cose-bounces@ietf.org] on behalf of Göran Selander [goran.selander@ericsson.com]
Sent: Friday, September 04, 2015 3:15 PM
To: Hannes Tschofenig; cose@ietf.org
Subject: Re: [COSE] Multicast Use Case

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" <hannes.tschofenig@gmx.net> 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
>

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.