Re: [COSE] Multicast Use Case

["Jim Schaad" <[e-mail]>]

Hannes,

I think that characterizing draft-kumar-dice-multicast-security as some type of DTLS may be a huge misnomer.  On first read it is not matching a great deal of what I think of as being TLS/DTLS.   For example, all of the record layering that is present in DTLS does not appear to be here, and I would assume that none of the starting handshaking is going to be present here.

Looking at the figure 2 in that document appears to have an overhead of 13 bytes, but I am not seeing the sender ID that you are talking about so I am unsure that your analysis of the sizes is going to be correct for this.  It is definitely not true if the multiple layering of TLS is going to be used.

I am having a hard time with the example you gave, I put it into cbor.me (after removing comments) and it generated a syntax error.  After generating it on my own, I came up with:

[
     2,  // encrypted message
     h'a2010a0547089f52fa000000', //  Protected headers
	//  {1: 10, - algorithm AES-CCM-16-64-128
               //   5: h'089f52fa000000' - nonce of 7 bytes}
     {     },  // Unprotected headers (none)
     h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', // encrypted message + authentication tag
     [
       [
         h'',  // Protected header - none
         { //  Unprotected headers
           1: -6,  // Algorithm direct
           4: h'01' // sender ID
         },
         h'' // No cipher text
       ]
     ]
   ]

Which maps to 56 bytes with a 28 byte message, using my best guess from what you are saying you get a 42 byte message with you "DTLS" message.  The current difference in overhead thus being 14 bytes rather than the 19 bytes you have below.   I expect that this difference will decrease as time goes by.  We have a proposals on the table which would reduce the size of the COSE message for handling of single recipient messages, but it is not clear which, if any, are going to be incorporated into the document.  Part of this is a question of what the implementation sizes are going to be.  

Although the kumar document says that there should be significant code reuse between it and DTLS, I am not sure that I would agree with this.  It seems to be that it is just reusing small portions but it would be a significant re-write and would need to  have a corresponding complete security review.

Jim



> -----Original Message-----
> From: COSE [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Monday, August 31, 2015 12:22 AM
> To: [e-mail]
> Subject: [COSE] Multicast Use Case
> 
> 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