Re: [COSE] Multicast Use Case

[Hannes Tschofenig <[e-mail]>]

Hi Jim,

thanks for looking this topic.

The correct figure to look at is in
http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08

         +---------+---------+--------+--------+-----------+--------+
         | 1 Byte  | 2 Byte  | 2 Byte | 1 Byte | 5 Byte    | 2 Byte |
         +---------+---------+--------+--------+-----------+--------+
         | Content | Version | Epoch  | Sender | trunc_seq_| Length |
         |   Type  | Ma | Mi |        |   ID   | number    |        |
         +---------+---------+--------+--------+-----------+--------+


              Figure 4: The adapted DTLS record layer header

Whether 'DTLS multicast' is a good name for this solution is something I
don't want to comment on but what it aims to do is to offer security via
a modified version of the DTLS record layer. The handshaking protocol is
not used for the establishment of the necessary keying material but we
envision something like the stuff developed in ACE could be a candidate.

Based on the feedback we had gotten in the past we are now looking at
replicating the same functionality at the application layer and the work
here in COSE seems like a useful candidate.

Of course, we want to copy the features while keeping the complexity /
overhead as low as possible.

Thanks for the updated example.

Ciao
Hannes

On 08/31/2015 10:02 PM, Jim Schaad 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 (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
> 
> 
> _______________________________________________ COSE mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/cose
>