Subject: [core] Additional use cases for Group OSCORE

From: "Bradbury, Matthew" <[email-masked]>
Date: Tue, 14 Sep 2021 08:09:48 +0000

Hello all,

I recently watched a talk by Christian Amsüss [1] which included an introduction to the CoRE ecosystem, including OSCORE, where I asked if Group OSCORE supports multicasting unencrypted digitally signed messages. Below are some details of my use case for this capability, and also another use case from connected vehicles that may be applicable.

I have recently been using OSCORE in a project looking at task offloading from IoT devices to edge nodes [2]. As part of this project, a trust model was used to assess trust in edge node behaviour. We wanted to incorporate reputation beliefs from other IoT nodes. As an incentive to not lie about reputation beliefs or to tell different agents about different belief values, we have those beliefs sent in the clear with a digital signature for integrity, authentication, and non-repudiation. It is important that the reputation message is not sent multiple times and encrypted with a different key each time, as this potentially allows devices to lie about reputation.

My intent was to use Group OSCORE to multicast an unencrypted and digitally signed message containing reputation, but due to lack of support have instead attached a digital signature inside the CoAP payload. An alternative to multicasting unencrypted digitally signed messages that would be acceptable, is encrypting the message with a shared secret that all devices are aware of and then only sending this message containing reputation information once.

I am also aware of a similar requirement in connected vehicles, where CAM (safety) and DENM (event) messages are broadcasted where the content is unencrypted but digitally signed. Messages are unencrypted to avoid the time cost of setting up shared secrets for encryption which may impact on the safety of the sending vehicle and surrounding vehicles. There is some more information on this at [3].

[1] https://christian.amsuess.com/presentations/2021/summit-core/
[2] https://raw.githubusercontent.com/MBradbury/publications/master/papers/SAC-DADS2021.pdf
[3] https://www.etsi.org/deliver/etsi_en/302600_302699/30263702/01.04.01_60/en_30263702v010401p.pdf

Many thanks,

Matthew Bradbury | Lecturer in Cyber Security
School of Computing and Communications | Lancaster University

---

From: Göran Selander <[email-masked]>
Date: Fri, 17 Sep 2021 11:01:52 +0000

Hi Matthew,

Thanks for your input. These are interesting examples of where signed unencrypted data could makes sense.

A question about the first example. Disregarding that well-known secret keys are not much different from no encryption, why doesn't sharing a well-known key in the group of nodes address the issue? I understand that if multiple keys are availble and different reputations may be cast with different keys then contradicting reputations can be cast. But why does the key have to be used only once? Couldn't some underlying parameter provide freshness, like the OSCORE Partial IV?

In the second example it is clear that the message needs to be communicated faster than keys can be established with the receivers. (Or use shared well-known keys, but then again I don't see much difference compared to no encryption.)

It would be straightforward to define the group mode of OSCORE with signed unencrypted messages. But OSCORE uses COSE algorithms, and there is no NULL encryption algorithm in COSE (yet). The main reason why encryption is mandated is to avoid potential conflicts with best current practices, in particular to avoiding pervasive monitoring (RFC 7258). But I think your examples make clear that in those cases it is motivated to share this information in plain text. Not saying that we should make this change now, but definitely a valid input. What do other people think?

Best regards
Göran

From: "Bradbury, Matthew" <[email-masked]>
Date: Tuesday, 14 September 2021 at 10:11
To: "[email-masked]" <[email-masked]>
Cc: Göran Selander <[email-masked]>, Christian Amsüss <[email-masked]>
Subject: Additional use cases for Group OSCORE

Hello all,

[1] https://christian.amsuess.com/presentations/2021/summit-core/<https://protect2.fireeye.com/v1/url?k=9a852cff-c51e15fa-9a856c64-86959e472243-e16829dd36b407e0&q=1&e=b8e95696-b1d0-4d51-80e3-c4736c9cb0dc&u=https%3A%2F%2Fchristian.amsuess.com%2Fpresentations%2F2021%2Fsummit-core%2F>
[2] https://raw.githubusercontent.com/MBradbury/publications/master/papers/SAC-DADS2021.pdf<https://protect2.fireeye.com/v1/url?k=c08ab16f-9f11886a-c08af1f4-86959e472243-f0db8b3dd10cc487&q=1&e=b8e95696-b1d0-4d51-80e3-c4736c9cb0dc&u=https%3A%2F%2Fraw.githubusercontent.com%2FMBradbury%2Fpublications%2Fmaster%2Fpapers%2FSAC-DADS2021.pdf>
[3] https://www.etsi.org/deliver/etsi_en/302600_302699/30263702/01.04.01_60/en_30263702v010401p.pdf<https://protect2.fireeye.com/v1/url?k=c69df746-9906ce43-c69db7dd-86959e472243-c99ce90d8e31b3c7&q=1&e=b8e95696-b1d0-4d51-80e3-c4736c9cb0dc&u=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_en%2F302600_302699%2F30263702%2F01.04.01_60%2Fen_30263702v010401p.pdf>

Many thanks,