Re: [COSE] Multicast Use Case

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:cose-bounces@ietf.org] On Behalf Of Somaraju Abhinav
> Sent: Monday, September 07, 2015 12:55 AM
> To: Göran Selander <goran.selander@ericsson.com>; Hannes Tschofenig
> <hannes.tschofenig@gmx.net>; cose@ietf.org
> Subject: Re: [COSE] Multicast Use Case
> 
> 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 [cose-bounces@ietf.org] on behalf of Göran Selander
> [goran.selander@ericsson.com]
> Sent: Friday, September 04, 2015 3:15 PM
> To: Hannes Tschofenig; cose@ietf.org
> Subject: Re: [COSE] Multicast Use Case
> 
> 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 dont define this in COSE,
someone
> may be tempted to do this elsewhere.
> 
> 
> Regards
> Göran
> 
> 
> 
> On 2015-08-31 09:22, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
> 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
> >
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> 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.
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose