Re: [COSE] Multicast Use Case

[Sandeep Kumar <[e-mail]>]

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]> 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
>