Re: [COSE] Multicast Use Case

["Kumar, Sandeep" <[e-mail]>]

The keoh draft would be applicable here for comparison.

The overlap is in sense of additional code to enable secure multicast if DTLS is already present for unicast. Yes alerts and handshake from unicast are not used in the multicast (but DTLS unicast can be used to do the key updates for multicast).

I think you are misreading the TLSPlainText, TLSCompressed, TLSCiphertext. They are not wrappers in the sense that each one is embedded inside another. They are just structs to indicate the present status of the processing, only the length and the opaque fragment  gets modified at each stage while the content type and version are copied to the next struct. See how TLSCompressed is constructed from TLSPlaintext in 6.2.2 in RFC 5246 (TLSCompressed.fragment is the compressed form of TLSPlaintext.fragment and not TLSPlaintext). There are no additional wraps/layers inside if you look closely.

Regards
Sandeep

From: COSE [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 11:59 PM
To: 'Sandeep Kumar'
Cc: 'Hannes Tschofenig'; 'cose WG'
Subject: Re: [COSE] Multicast Use Case

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]<mailto:[e-mail]>>
Cc: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; cose WG <[e-mail]<mailto:[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


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.