Re: [COSE] Multicast Use Case

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

I did not find the keoh draft because it expired at the beginning of July.   Which is the draft that I should be looking at?

 

I could easily be wrong about the code reuse.   On the other hand I don’t know what the levels are that are being re-used from TLS, so it can easily be that I have misunderstood what is going on.  On the other hand, I am not seeing a great deal of overlap with what I think of as DTLS.    I think there is a difference between being able to  re-use some small pieces of a DTLS system and saying that it is easily adaptable from a DTLS system.

 

Do you use the three layer wrapping of DTLS: TLSPlainText, TLSCompressed, TLSCiphertext?  I assume that you do not use the handshaking.  I don’t think you have any of the fatal error conditions.  I don’t know if this is a unidirectional cast that people cannot raise fatal alerts from.   I assume that you don’t do the change-cipher, but that is going away in 1.3 anyway so it is not a big deal.

 

jim

 

 

From: Sandeep Kumar [mailto:[e-mail]] 
Sent: Monday, August 31, 2015 2:28 PM
To: Jim Schaad <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>; cose WG <[e-mail]>
Subject: Re: [COSE] Multicast Use Case

 

Hi Jim

You seem to be referring to an alternative version of the draft than Hannes used. The draft Hannes used draft-keoh-dice-multicast-security-08 uses SenderID to separate the nonce, while draft-kumar-dice-multicast-security derives new keys per sender (based on a single key and SenderID). the change was due to a difference is preference in my co-author but should not change the overhead.

Finally I disagree on your assessment on code reuse, it had been implemented with minimal changes needed to an existing IoT DTLS library.

regards

Sandeep

 

On Mon, Aug 31, 2015 at 10:02 PM, Jim Schaad <[e-mail] <mailto:[e-mail]> > wrote:

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 <http://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] <mailto:[e-mail]> ] On Behalf Of Hannes Tschofenig
> Sent: Monday, August 31, 2015 12:22 AM
> To: [e-mail] <mailto:[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 <http://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
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/cose