Subject: Re: [COSE] Multicast Use Case

From: Göran Selander <[email-masked]>
Date: Fri, 4 Sep 2015 13:15:57 +0000

Hi,

Independently of the multicast use case, there is a secure communication
setting that is similar to this example which I think deserves being
considered in COSE.

What I expect to be a common setting is that the receiver has already
established a security context, including algorithm, key, sequence
number/used nonces etc. with a context identifier that is locally unique.
In this case the only information that needs to be passed in the message
is context identifier and nonce/sequence number together with ciphertext +
tag.

You may of course argue that you should use the existing COSE_encrypt
format.  But since a) the assumptions are quite different, b) the
optimizations may be significant and c) this may be a common mode of
operation, I think it actually deserves a (sub-)format of its own. If we
don’t define this in COSE, someone may be tempted to do this elsewhere.

Regards
Göran

On 2015-08-31 09:22, "Hannes Tschofenig" <[email-masked]> wrote:

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 5 Sep 2015 13:41:11 +0200

Hi Goeran,

I completely agree with you that having an already established security
context will be common for a number of use cases. I posted the use case
for multicast in the lighting environment since this is something I am
currently working on with Sandeep and Abhinav.

The OAuth access token is another such use case.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 5 Sep 2015 14:04:15 +0200

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:[email-masked]] On Behalf Of Hannes Tschofenig Sent:
>> Monday, August 31, 2015 12:22 AM To: [email-masked] 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.
>> 
Since there is no sequence number defined in COSE I put the epoch and the
>> sequence number together into the nonce field.
>> 
>> [ 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/cose
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 5 Sep 2015 14:37:51 +0200

Hi Stephen,

the discussion in DICE was controversial because there was some
reluctance of relying on symmetric keys since it allows anyone in the
multicast group to inject messages without the ability to authenticate
the sender.

I had a chance to look more into this issue with our participation in an
EU funded lighting project and I believe that the use of symmetric keys
in combination with a key distribution is OK. (The project is called
OpenAIS and consists of a number of the big players in Europe in the
professional lighting sector.) Of course, we will have to discuss this
in more detail in the ACE working group when we get to that point.

To come up with a comparison we obviously have to compare the solution
we would be using at the DTLS layer with an application layer solution.
That's what I had been trying to do here.

We also did not find other use cases that the same type of requirements
as professional lighting has. Other use cases may not have the same low
latency requirements, may not need to rely on IP multicast, or have
higher security requirements.

Hence, lighting does not introduce a generic mechanism but it is still
an important enough area to standardize a solution. I still believe we
should standardize solutions in the IETF that are relevant only for
certain industry sectors.

Ciao
Hannes

PS: In general, my initial review was not really about a specific use
case but rather about the fact that (a) the currently provided examples
were difficult to understand since they didn't contain a lot of comments
and (b) they did contain anything I was looking for. They most likely
have their origin in other use cases.

On 09/01/2015 01:17 AM, Stephen Farrell wrote:
> 
> 
> On 31/08/15 23:35, Carsten Bormann wrote:
>> Jim Schaad wrote:
>>> 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?
>>>
>>
>> Now you got me confused.
>>
>> https://tools.ietf.org/html/draft-keoh-dice-multicast-security-08
>>
>> expired on January 4, 2015.  Are we talking about the same documents?
> 
> And... the proposal for the dice WG to adopt that functionality
> (regardless of draft) has been controversial. So I think that means
> that one cannot directly compare encoding sizes, as we do not know
> that a DTLS approach to multicast is workable. I'n not saying here
> that one cannot depend on what's in these drafts, but rather that
> we might not be doing an apples to apples comparison.
> 
> S.
> 
> 
>>
>> Grüße, Carsten
>>
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cose
>>

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 7 Sep 2015 07:55:05 +0000

Hi Goran,
I agree with what you are saying. At least in the Multicast use case, we are able to use locally unique context information (which could be sent out during the key distribution phase) to establish a context that would allow the identification of the algorithm.
Abhinav
________________________________________
From: COSE [[email-masked]] on behalf of Göran Selander [[email-masked]]
Sent: Friday, September 04, 2015 3:15 PM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [COSE] Multicast Use Case

Hi,

Regards
Göran

>Sequence Number + Sender ID, 3 bytes for Content Type and Version fields].

_______________________________________________
COSE mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 9 Sep 2015 08:43:01 -0700

I am seeking a piece of information on the DTLS solutions for the ACE group.
Do these messages go as top level UDP objects or do they still have a CoAP
wrapper?

Jim

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
> Sent: Monday, September 07, 2015 12:55 AM
> To: Göran Selander <[email-masked]>; Hannes Tschofenig
> <[email-masked]>; [email-masked]
> I agree with what you are saying. At least in the Multicast use case, we
are able
> to use locally unique context information (which could be sent out during
the
> key distribution phase) to establish a context that would allow the
identification
> of the algorithm.
considered in
> COSE.
number/used
> nonces etc. with a context identifier that is locally unique.
is
> context identifier and nonce/sequence number together with ciphertext +
tag.
> You may of course argue that you should use the existing COSE_encrypt
format.
> But since a) the assumptions are quite different, b) the optimizations may
be
> significant and c) this may be a common mode of operation, I think it
actually
> deserves a (sub-)format of its own. If we don’t define this in COSE,
someone
> may be tempted to do this elsewhere.
> 
> 
> Regards
> Göran
> 
> 
> 
> >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.
> >
> >group in the professional lighting environment, as explained in the
> >DTLS multicast document.
> >
> >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
> ________________________________________________________ The
> contents of this e-mail and any attachments are confidential to the
intended
> recipient. They may not be disclosed to or used by or copied in any way by
> anyone other than the intended recipient. If this e-mail is received in
error,
> please immediately notify the sender and delete the e-mail and attached
> documents. Please note that neither the sender nor the sender's company
> accept any responsibility for viruses and it is your responsibility to
scan or
> otherwise check this e-mail and any attachments.
>