Re: [core] Additional use cases for Group OSCORE

Göran Selander <goran.selander@ericsson.com> Fri, 17 September 2021 11:02 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE183A13FC for <core@ietfa.amsl.com>; Fri, 17 Sep 2021 04:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JazvwzK8orq for <core@ietfa.amsl.com>; Fri, 17 Sep 2021 04:02:00 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70053.outbound.protection.outlook.com [40.107.7.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DD83A13F9 for <core@ietf.org>; Fri, 17 Sep 2021 04:01:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LYC+auje6s/rzqDcqXJVzCqG2OWoYvQbGyTonl0KcK2aMSw4/mR6jkm250qnOutsZcaN3bVoJKtlwkdLVdRWuS8Ui88hbTuaS61uR4AQN5i++YyFpZAzIHS5ceRIOZ3QRpLrQXfuqmXpdyBUM66TR9uvHHcKvU42teMp7YfComj9KC4WhV17EtnT69HLVl/Z7VlqtdAcU/3ZT1Yv+Lox8mNwM3k4pHYBwwgKtTwZbpZrS7/44OzMUzp3mIr1FsJ3cl6mhv14lCEwHBiuiI3xcWUsW1yyBAvA3G772XJx36zPy6W/BC0NHZnHnl/kn5TWFPls74yoY9YigtBbOZ9H6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kyy6cUCGaClAqmbVGoR+EArc7WtcPMiXKjztTHB2lkw=; b=b2CJv0e1bTAz3iLe0cmc/O59x3bSXTRBabmo2oLqQ4OsCIuUetToVYZL34tlRFYNZbt/XCqSO0/HXtNnUcWD4ckCOY/JzqdOxQpud8gYX/PNCncLxdfuY3bAopgU2/IcnFtUrGos5MkSjd6jsAJKgqvrXSqCJDIG9WaJXc5qf/IMl+Q2GXtKDaJ+lVxH/0wBiGJYL2BMjydDPp2R6NJLt8yuvabn8Df9biYh6QvhEXeAkNY97e1wPyx3/y3SSAx22TEfEcmT/3C0jVXAgpqyCmVLQw/UY6xdwsx9G0l4aXSzjOC7vHiO3MxP71mzC3JTqU+CnQrtFin3GHqpyT1P5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kyy6cUCGaClAqmbVGoR+EArc7WtcPMiXKjztTHB2lkw=; b=bB2d30QS8kKxvRetg3lgE37htPJFNqhObReV9hNAZ3KnI4W/x749bSZof17yjuzIx1Gf3muF67YMXhkMQOUufUEGxu+ZiwPnMrZLBcXKM6fcPAxZG17nEFBB4wxvXQydnmXZDgWCrgDyPphVxW94te+g61S8d+8BcbjPjRFGOKU=
Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:28::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.12; Fri, 17 Sep 2021 11:01:52 +0000
Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e%7]) with mapi id 15.20.4544.009; Fri, 17 Sep 2021 11:01:52 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: "Bradbury, Matthew" <m.s.bradbury@lancaster.ac.uk>, "core@ietf.org" <core@ietf.org>
CC: Christian Amsüss <christian@amsuess.com>
Thread-Topic: Additional use cases for Group OSCORE
Thread-Index: AdepPvWBxRUPF0VTRBWaJQfnO46XhAChTjWA
Date: Fri, 17 Sep 2021 11:01:52 +0000
Message-ID: <049EF3EB-287C-4CCA-BC81-C27CB915095D@ericsson.com>
References: <CWXP265MB099943F6D34A935386EFD90780DA9@CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP265MB099943F6D34A935386EFD90780DA9@CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.52.21080801
authentication-results: lancaster.ac.uk; dkim=none (message not signed) header.d=none;lancaster.ac.uk; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bab318d9-274d-4a75-2983-08d979ca8e03
x-ms-traffictypediagnostic: HE1PR0701MB2139:
x-microsoft-antispam-prvs: <HE1PR0701MB21392832A3149FBBD6F16B25F4DD9@HE1PR0701MB2139.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lOdeInioMp9NZxTyPbqubrIrhrgYIm+HEgE4om3LVfV6RZQh9XY7SVnepHrNw+uD/3x1otglIGdHEF+Bt0em447KI//tt/eKEzc9HtmmI4z/6FTo12UDL8MYzjbwrh4Z0DOr/ElFCWhPeIqbnduEd3oqrc8cXO7Uxo47DaQxkleQA0RSQ49Qxe3shNEIP1Hj8W9DwdvuF0EaKwawot+QUIlsLYOl2F6K6Wj1GQm/1qjmpvjCNWHv1ASkquQQnb0n4WEYxjBHsgAtT0ZBOKoYcCmMJBvJ2RZU3uafCNojBUog46corJmD5fkWmCDeJaPSsieyk8+StQMSzwIERM3FOkEQZUkV5BdPngQOrQu2WEqJKj1/+Lj9x3rfU+LyOOooxBN3yiJjMkiP+6Ller4NkshuThmXgj+hjiChn40Biq4VHa2teMUI/k8xlAHlFKnNrsvtrlE/EkAXPLlxsPiiiiN4//k2pmu1mrxXC8TRLwNHt0kTO0f7ZqjEebf0Ja8lXXhIzVYU7pAjBfdW7iAED4H+AE0VnBxxmfUE14H1OtgOc5dF3gpmrxfCFR1MXH00uX9nkKuLb0HLxdMc0b7MX1ZEyryTj61ImaQZblOYhKo9ZtobKNbAVV/UbZa6RalDu/I33SqmzFePgz2krjTLNHFEAjrOBCJJjCdZ3DQBJzmhdIXOixkCxWCo5LEgeQY1GqcG2mpO3g4JaCSY53Wt9Bq3oYIdfc4nmbzCDp763UBZ5YJyQ4Bck09Ly4/I3rXW36Z0tOKuGIugr6s8vRsIfZSdPofe9exVvOhXy7VUvhQmM6yZhWUECJD5Sv3Uwo7Y
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(376002)(346002)(396003)(66574015)(36756003)(166002)(316002)(5660300002)(66446008)(8936002)(66556008)(66946007)(6486002)(64756008)(76116006)(110136005)(122000001)(38100700002)(86362001)(4326008)(33656002)(2906002)(26005)(38070700005)(66476007)(966005)(6506007)(8676002)(478600001)(85202003)(6512007)(85182001)(2616005)(53546011)(186003)(71200400001)(83380400001)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: oxmy18n4qQKdqY3TxZAW+EggJ9/UgD4AxLhN9CYWfNpWwEp3P7vlbCaBVDkkgpAPCdrLP5B0NAkuH7DqVo5hMMjBYSnIs7rl/WZGBMVK9GDAHivx9CzzjRdEGcihjrN2gFfSAos++kiA2hfLs8wZ4jcocaakz5k6gdOBFEgYiRXFcH1dcyPNdm96Sq1askkYP9ljEWxBMIsAvtsF5GTyo8GOx3x1J9K7QkorLNoz8uDS1OMek98IuVTF7Sui5r/T6BKwd/2KzNxLQ4py9xFepqKo3JZwCDDjZ27XGyWGdAD+gNNEfoJRF7tUToA+H0/IC8EqPFZwZhvtp2Yk0K0sGmT5UgtMKNsW/C6DLAzApkXeWAffO3SMtQffSSEQfzTyeByXEzU3Bt4t8j3u/qMwD+dKs8zf05FaXE7vCYcre5oCTaeUbBZ36WPdjBiu7+N1C7vQeQ0lX8aUcEZGM35QKmBBy+0QChvTrVg5h8Lpvag72U9V25p7jyYY3kZIBFQhMpyvzyzHYafrkdTZhRYBNBHVAfG+8JU8tIlkp+2KzUY6zc4ki04YBd4mpeZzlqx5sQrF+wUOfjKLaxd0dtimQ4uYZ27TL2hgF7mZzZ9S57impsFoSoDM0zEa/wlKz4kp8UjRmamqL5sG6wPMLN06h9ixf87QaIjiWsLeVRLyek3LD8PiADVYveUD8lq8eGegPi1jfgqB8eM6iAcIdhKs2RwaaFGoXTN0dv6u66t0YVvmO+MyNudEHZ0/1gveI9nzluckUbeTvajh0YjW8gRVWhxKm2QJNhA5J/6TRMg5NhztZHXmntZp/UNnz5Pz1yLbOi0c6Qdifi2zjhdKTiN4Lucl2PaR2PFB3PXCmjI6UT5KO29TbzFC8qvEEChOZOYBLZzhjPWTq/OUj4k4+e1eEWJ0V4LRI2q4xFI6nliflhtceziGYKJqjdxaeg97wiqnnuHXZYdvVkL1fn14xv/pANIbyorFHkPA3z2egFHBGtM8OpvrI16e1GEj765c6s30ZJOtqImKeTZx+irkbdcrYbKf6KWTJ5weYVt1b5QYui/MRu9ib5VDS38BsD3jLEiwNkKmQumqxm0G0jlFQt7yw/Ch3pLSMJTRQEYu6G92503aqSNdlT4Rcv5cepRdyW/CKjuaYlEhGpWQvCcPl5VEXxuR6Rk0lqOXZiu1xuLu97g6tRDp6J82TVb43Os4r+pc7AHvPCJBjjf52iDgn9LC/hjO0ieozwACahljShB6feppT7MIYbgPUVkpUTDTZuO4RACJm+jgh2c9bVALKA5pIvl+Wqkd0cv6+9IG0gxglOn9cAGsVdiEY5RsEph++RjXUT/qFZJg+e7LMCia7USU5A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_049EF3EB287C4CCABC81C27CB915095Dericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bab318d9-274d-4a75-2983-08d979ca8e03
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2021 11:01:52.1563 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Bs5QKRyOdVzGFFco8KySgpGI0iD/p3VsbpZst39EQutFzYX5g9rIkeFVZgSOUhW7QpD2jnSgrAt/+aucLEQtxaTYMRJgkHTE5LNjiXHjuq8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2139
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/SeraA5k62WgVIHJ21dI6Q-3lZ2k>
Subject: Re: [core] Additional use cases for Group OSCORE
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2021 11:02:06 -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" <m.s.bradbury@lancaster.ac.uk>
Date: Tuesday, 14 September 2021 at 10:11
To: "core@ietf.org" <core@ietf.org>
Cc: Göran Selander <goran.selander@ericsson.com>, Christian Amsüss <christian@amsuess.com>
Subject: Additional use cases for Group OSCORE

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

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