Return-Path: X-Original-To: gen-art@mail2.ietf.org Delivered-To: gen-art@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B595A5E35BA8; Fri, 5 Sep 2025 14:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ri.se Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXPlS3hDdQt2; Fri, 5 Sep 2025 14:15:19 -0700 (PDT) Received: from MM0P280CU005.outbound.protection.outlook.com (mail-swedensouthazon11010032.outbound.protection.outlook.com [52.101.74.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 853B75E35B9C; Fri, 5 Sep 2025 14:15:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iW7s3RNP8iL5AFO4kRDP5QoZLabsN1ouGcY4qQTW3+Zxpx6qs07uYUg/tnhttmYzZVJ8uZxn+tXiT9SO0g9r1IYGXsGEQ3aBxblNSAT3LxQciVaILDje/aPGOrmRAgg+kdcBSHsO82TnYt+mm2bZpMS3JiC5LYMVLPuU0PR+AVLZx+07Kce3lrbSdBSz7vn6nTK8FljFKOmMbUj+82H0nUyaI2o25wdYDBCRDOpmf6ay9eelsvMEg9zqBK5+8CHjOrKJyMVnTtnK72vT+BUbUmQ8efJOKkXDvLYU2MqE6mpPCZVIpKeKYoqgMxi5Hh2moUFXYFzDPfG5T8hvK9aJkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6CbYqk7YX+mH4XhR5huiqVSBRk/AiAqXbVf3AZbu5Z8=; b=QPGsHU4YCU1xOKHgvzM0sLmlomOypRyNxiufCH43fKFVHZAMo6O+ee4zG1/+VaCn1e3DUCukv+Yy33Ynta8sQJyscgu11AWSqT7xxnn6Hbj6K7lu0YzcEXVMfespaBK2At7kd4ZDo095Y5obOf589sUgxv9+hiKUM2J2FCiS0Bv/1CtAsY+Yd3FmOC5Kl+N5izxCUsbwHEqcihZzXXRcEF5I3wFZ32xW3zsBstQJ/ZpWOFs9i80l4mzo4iepI+50zi0q5eml3/B3I998ulzfKrHfo6C1K7E6kYvt1W7PF5XfGennMQxl2YeOaDly6wrsY1sONCS5ukalSA6QMcabTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6CbYqk7YX+mH4XhR5huiqVSBRk/AiAqXbVf3AZbu5Z8=; b=l4VuhsYsNuFvWrNQ/b6r7caFhcEW0X+o3Q/xEF8sTekEpTlOjMGXZvh6fErelpHVYI0lEIHzqX+t6Z74SENQCvK/9kUOoaZ56Lfbu/mM95fSsbRr/S0OMGk5E4oPKqgttlR7lgxhlfbWFomctT/8psG+cNWbG9bWYnQO36nSbGvvj3H0OGxUO570IjYcLS5oSaTEp5Ett+IOD8oAv03eoGRUX1GUkkq073XaTRQJfjwGB9iYZIJjpuowZ7Qipvf2M3/25TnSluOOrQKSZ8ia3VvjZcLhxeG4ZJRSWZA1pBXoOYyw6g6HzidgKyIuswJCGHMFkBSpybxbwh5vF0ZS0g== Received: from GV3P280MB0450.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:11::7) by MM0P280MB0087.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:14::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.18; Fri, 5 Sep 2025 21:15:08 +0000 Received: from GV3P280MB0450.SWEP280.PROD.OUTLOOK.COM ([fe80::660a:b243:998d:77df]) by GV3P280MB0450.SWEP280.PROD.OUTLOOK.COM ([fe80::660a:b243:998d:77df%6]) with mapi id 15.20.9094.016; Fri, 5 Sep 2025 21:15:08 +0000 From: Marco Tiloca To: Paul Kyzivat , "draft-ietf-core-oscore-groupcomm.all@ietf.org" , "core@ietf.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-core-oscore-groupcomm-26 Thread-Index: AQHb/AHT2FC2jYZlrkaY1TIacjZY07SFWctl Date: Fri, 5 Sep 2025 21:15:08 +0000 Message-ID: References: <2278577b-c3c0-4744-945e-c81592ddd34f@alum.mit.edu> In-Reply-To: <2278577b-c3c0-4744-945e-c81592ddd34f@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_Enabled=True;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_SiteId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_SetDate=2025-09-05T21:15:08.168Z;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_Name=K2 Intern;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_ContentBits=1;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV3P280MB0450:EE_|MM0P280MB0087:EE_ x-ms-office365-filtering-correlation-id: a5facf85-1b81-4e32-52f2-08ddecc14af2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|19092799006|366016|7053199007|38070700018|13003099007|8096899003; x-microsoft-antispam-message-info: =?Windows-1252?Q?THD7nLiDjquFdH/xF+QSWOID16OdPY9NxR+Xl39kh0sMDh6j56Cwdbso?= =?Windows-1252?Q?FVHe/2CxHw0oU409MET1n475wGi13gkrC55GGC5sEvm+W/I5Bof93p5z?= =?Windows-1252?Q?nmQvLP5QCdyT5bG6pz9lbH/PuJ54wCTdY0GNPsskv4MvgASFeVYcAz0e?= =?Windows-1252?Q?IBdxexiNGoc1YqjBvtW1g3cpJ++VxRTUNGghFP8LfucGeMpi8sukLlPD?= =?Windows-1252?Q?4P1lDILuc4QIGVQN63yn38LQfSOJX95dqKR8k6U3ipHML5nWKagkb26E?= =?Windows-1252?Q?xDcoNbJzIEFMV18X6nMXQL6xB6/YTIGtBOCUPGZISGeYfXAO5SbuRvnn?= =?Windows-1252?Q?dqlQ9ZmrsEp170mtzp7uQsiiMqPSkU7IbFz8Cx0ptdoUprpJEiCYmEmc?= =?Windows-1252?Q?wpuvMVE18zFW9pC1hMYEdsMNxs2QxBMOxnWTvD9zROtpFUivkUP77eEf?= =?Windows-1252?Q?Blvk8mMAbqUcAO4RkhvGGWjAF2eQV/KuOMVmswblXXv9e6hxc6XvEmOM?= =?Windows-1252?Q?noFoKVKLCerJ08xPvQJFppRj7/sltlTq/l/oIPOJSJLoj4fQTRwJuNXr?= =?Windows-1252?Q?1+yO11Ay0Q1kB3ZuOZ3t4efcdT0DTQTWc/m5BfbYv9P0aSSeMPa1znd5?= =?Windows-1252?Q?jWU2AZGUzhqxd9y2rxcHiMj7xqtuM20KgWn7vvji/VxG70QnGKg2g1XT?= =?Windows-1252?Q?hQAGBVpHYNVEpj35Q40Qx2nOuMyAWmdWvc5RbVL7kmIiBZAYRI42gvoD?= =?Windows-1252?Q?6PIAueLdRGeqfLvfzjOYJtPNyPg+Iv0FYNh0wdLWEOLbQcT1ga6JmPNn?= =?Windows-1252?Q?9m6iAfXUr5g1qQ+XNruGAWBtQDtB7TDRNcoH0fiGHvf949q78LPI+7HQ?= =?Windows-1252?Q?er6aq4Ps1l0lYZ/uucwGUPRVXQRuGXkv5646Bop8kmWkY8rLSMPyjuxP?= =?Windows-1252?Q?HHadaUmrCmmbsaGFJ00iVFb6B2iuHhty7CmnK1PHbt5LQq6jDShY7rW6?= =?Windows-1252?Q?v3XmFC3yZoWtJCB6Tqzh/OHssNecyKbdXgFLYJ6geZcwJH6I5GhutKr9?= =?Windows-1252?Q?9iw4BVkliEdd4drFPglYkgk8+3pd8aw3EaSHKnQ54+ejGcgxmhxsd4X8?= =?Windows-1252?Q?rZsA9ORk0qnxZ+ZX99TC5jz39gOB0UmVdT73Pz6mMixlVjh9H7pGjmnK?= =?Windows-1252?Q?pP4Jt7BX/0r/AkoEKKmz5PFa7m2Iros1CYXTRYbaTZbMiyUaKbKQMJ1g?= =?Windows-1252?Q?SmQ3esx9D7y0pSq0xaYqZGrAWnk3rdloduVB0W9gIqKIOIpzGvPGlrk+?= =?Windows-1252?Q?iEK0dzHfwYkZHvNpchWjxThIaxdE+5MZ8391xsvuvnyRbYSmJTiMjhi0?= =?Windows-1252?Q?4n4V3ii/SOpzYllsfD1eT+gXlXa1s7Rg9zbOmmvNmizeQxCGZDZtf88H?= =?Windows-1252?Q?fFj2dzFxKmrOHjyUC1fsY+DBThumogyv+Yr77ruUkgwZglmCXpqrkv9o?= =?Windows-1252?Q?1UEH4OdeLgwVtDr2BLKFzK1KxMjZqTWbOZbom/cLkmAAd6C0Z/E=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV3P280MB0450.SWEP280.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(19092799006)(366016)(7053199007)(38070700018)(13003099007)(8096899003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?9JOXXmygn5CT8gh0HeXlSKWyLo93fP9nA9Tdb0m076Irzyx0mbo8jqtI?= =?Windows-1252?Q?lsumc3wcFk/FNHbResyFVEo1roJkSx4Q7qNWOxCB2ndatv2wF5BXEqhz?= =?Windows-1252?Q?wotdQCoArpEwsfawR7U4sUcwnmjvzZBMs2YHpqE2e0dYTOU0NOSH0teK?= =?Windows-1252?Q?Mi/dcprpJc1B70JJ7fJUEnmNLvIE82ZAHxWnE//DWv5EF5u6XIIxGJ0R?= =?Windows-1252?Q?e1WzCkXwYgpVnPCibNyEsZIpsuMAk6G7J3afohpNfQnkG3bx9ESF1uez?= =?Windows-1252?Q?Gko0rnICHRzyyQ00q2UlN1GKNcXZOd8skx8ZvXJmwDRMrbDA6uvC174y?= =?Windows-1252?Q?tMd3wBTxyvDAkZEkcfQdcLCpKU5RLzYhawknag3SVF60OwFjncVNwAx1?= =?Windows-1252?Q?EuZubqO5wzUKRgHymdVLLvkfW/vfYFe5JzVCbVQLy/5obTgkeDGe9zl3?= =?Windows-1252?Q?M6O9dyxt2MPR67STyzWPy5LiwRiIf6GVH+lr1Qna483uCnoRBYgYQ2aZ?= =?Windows-1252?Q?QVJSXwf96/Ii7Y/dlcqkaIaSiNF2MCuM9RWw0fo29VND9UKzJMLLCaQj?= =?Windows-1252?Q?0C1ApQdWnFM5kzds1f0DUGJ38msCYd8NHVYULcGkgG2w1P4EnxutIv7c?= =?Windows-1252?Q?2EnG/uZvFCeTZ/aIE5PfP4Clrl1LCjhoXRSVEPmrRpIozVeNQRCiAUh+?= =?Windows-1252?Q?QbjGF1/fxszJQ9RjHcDV1xPoc6VZe9FZzPx41u0SzQpSWAtmS8BhpFd5?= =?Windows-1252?Q?MLO+vTYA96b4r9Y05zTbtxejdubZdsJDfHOrPYGy/ZD3bLovRlcC44z1?= =?Windows-1252?Q?0MKU37dJPXZfWdtc6/BUlsjTQ9Yy9HyQlNhHVid/9FUIGNm2oxdozmfX?= =?Windows-1252?Q?Ut2AXGN1X59LL2WwJv2mOX4/eE5MARFCOxhc6m1z4/6adCTocrAxSVNi?= =?Windows-1252?Q?jyPVsGNyaTvPO67Fnlzej3VdLPAzy1+go/3VPSo/YEAt9CMj+Emg4EfF?= =?Windows-1252?Q?YMeC+DMDThuzuP4/QGKm1IvdWyFTugUZNz3UCX59rOjjioQdUE603zZ4?= =?Windows-1252?Q?Bf0no+/ghW9eHahBj5HPzXXYeiF/kxAYFinF921W3cewlRQYJok8KGtG?= =?Windows-1252?Q?Wal467VXT5Ytq51lA13DIHmpA4o8P4/fCB2LPdIGYcj+1wJdHY81oIg+?= =?Windows-1252?Q?lDrf/XEgFdU6Pq2xlp14E0kD4A7xG17yAFemz+HSyS/KEfDuwen/ZZkS?= =?Windows-1252?Q?UHRse2kQW/dfJyrxomgd8UXmaIzpRC+Z3ObFvNYBz7mwfVt3Your5ivr?= =?Windows-1252?Q?rGmSxd4gAZFeM7rhoBuLy2/oSSAXneH8lKHgfIbVOzsOdB1Zk1yjf2si?= =?Windows-1252?Q?l6DNyD+qjUIbuylo8IUfCliEjwinGbv/sDFYo5VexxGpVOuGfKjXIW1W?= =?Windows-1252?Q?4YxBEmv29lMBb9g19xcScSc2L4ujtaNwyfOERfCtJdRF6MwvxuPSmqDk?= =?Windows-1252?Q?rtY4J0VTzw4HfMENNtRDQQonvjaQZOls3bvZrqp3Hawcb8I0l1taytBZ?= =?Windows-1252?Q?XFX8rFO0tpsE/hXe5LpPpVWy2Wco/08CFMDoyvqlWnIaTLQ53n+Xq2JH?= =?Windows-1252?Q?3GkzeYsECLPUlj6oXxRDyqxRJ8htNOtj+JgbjLWeqtNfAashQJhWYeNT?= =?Windows-1252?Q?xrHs1Q5mCtQ=3D?= Content-Type: multipart/alternative; boundary="_000_GV3P280MB04506A5F81EB69EC160DC9349903AGV3P280MB0450SWEP_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: GV3P280MB0450.SWEP280.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a5facf85-1b81-4e32-52f2-08ddecc14af2 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2025 21:15:08.6508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3n1rIBlRIdEXNgXYw1rZ1vwxZ3bB+m1DAzraSPaWWpnAAbEF9qAWdy/n03mVt3RBfl22wCUaXltM0vz9QiAFtg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MM0P280MB0087 Message-ID-Hash: W4KEMRARUZMR2YPGWHI5Q47QJYMMVCUL X-Message-ID-Hash: W4KEMRARUZMR2YPGWHI5Q47QJYMMVCUL X-MailFrom: marco.tiloca@ri.se X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-gen-art.ietf.org-0; header-match-gen-art.ietf.org-1; header-match-gen-art.ietf.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: General Area Review Team , "last-call@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BGen-art=5D_Re=3A_Gen-ART_Last_Call_review_of_draft-ietf-core-os?= =?utf-8?q?core-groupcomm-26?= List-Id: "GEN-ART: General Area Review Team" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_GV3P280MB04506A5F81EB69EC160DC9349903AGV3P280MB0450SWEP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Paul, Thanks a lot for your review! Please find in line below our detailed replie= s to your comments. A Github PR where we have addressed your comments is available at [PR]. Unless any concern is raised, we plan to soon merge this PR (and the other = ones related to other received reviews) and to submit the result as version= -27 of the document. Thanks, /Marco [PR] https://github.com/core-wg/oscore-groupcomm/pull/116 Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se ________________________________ From: Paul Kyzivat Sent: Wednesday, July 23, 2025 8:44 PM To: draft-ietf-core-oscore-groupcomm.all@ietf.org ; core@ietf.org Cc: General Area Review Team ; last-call@ietf.org Subject: Gen-ART Last Call review of draft-ietf-core-oscore-groupcomm-26 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at >. Document: draft-ietf-core-oscore-groupcomm-26 Reviewer: Paul Kyzivat Review Date: 2025-07-23 IETF LC End Date: 2025-07-29 IESG Telechat date: ? Summary: This draft is on the right track but has open issues, described in the review. Comment: This document notes "Readers are expected to be familiar with" (a daunting list of things). This was very challenging for a reviewer, who is not. But I did read the whole document. I am incompetent to raise issues about the essence of this document. Rather, I have focused on more superficial aspects. ISSUES: 4 NITS: 4 1) ISSUE Section 2.6.2 says: "If an implementation's integers support wrapping addition, the implementation MUST treat the Sender Sequence Number space as exhausted when a wrap-around is detected." I think I understand the issue, but question how it is stated. Just because the implementation does wrapping addition on integers shorter than 40 bits, that doesn't mean the implementation isn't capable to doing proper 40 bit arithmetic. There must be a better way to say this. Perhaps: "An implementation must treat the Sender Sequence Number space as exhausted when the Sender Sequence Number approaches the maximum value it can properly increment." Also, if an implementation has difficulty handling 40 bit integers, won't that also be a problem if it *receives* big sequence numbers? =3D=3D>MT Thanks for raising this detail. We have rephrased as below. OLD > If an implementation's integers support wrapping addition, the implementa= tion MUST treat the Sender Sequence Number space as exhausted when a wrap-a= round is detected. NEW (emphasis mine) > If an implementation's integers support wrapping addition, the implementa= tion MUST treat the Sender Sequence Number space as exhausted when a wrap-a= round is detected **upon incrementing the value that has been used as Parti= al IV**. On the point raised in the last sentence of the comment, that's not suppose= d to be a problem. In the OSCORE option value, the Partial IV can be up to = 40 bits, hence a compliant recipient must be able to handle that if it happ= ens. That's simpler than the case discussed above, since it does not involve ari= thmetic operations or other manipulation of the Partial IV value. It's just= about taking and using the Partial IV value as-is, in order to, e.g., perf= orm replay checks against a replay window (see Section 5.3), build an AEAD = nonce (see Section 5.2 of RFC 8613), or build the external_aad for processi= ng a message (see Section 3.4). <=3D=3D 2) ISSUE Section 6 says: "An endpoint MUST be able to distinguish between a Security Context to process OSCORE messages ... and a Group OSCORE Security Context ... To this end, an endpoint can take into account ... Alternatively, implementations can ..." Why offer alternatives? Why not specify a single unambiguous method? If there is reason, it would be good to discuss the pros and cons. =3D=3D>MT We have updated the second paragraph of Section 6 "Message Reception" as be= low. OLD > To this end, an endpoint can take into account the different structure of= the Security Context defined in Section 2, for example based on the presen= ce of Signature Algorithm and Pairwise Key Agreement Algorithm in the Commo= n Context. Alternatively, implementations can use an additional parameter i= n the Security Context, to explicitly mark that it is intended for processi= ng Group OSCORE messages. NEW (emphasis mine) **The way to accomplish this distinction is implementation specific. For ex= ample**, an endpoint can take into account the different structure of the S= ecurity Context defined in Section 2, **e.g.,** based on the presence of Si= gnature Algorithm and Pairwise Key Agreement Algorithm in the Common Contex= t. **Alternatively, at the cost of increasing storage**, implementations ca= n use an additional parameter in the Security Context, to explicitly mark t= hat it is intended for processing Group OSCORE messages. <=3D=3D 3) MINOR ISSUE Section 2.4 says "The authentication credential of the Group Manager SHOULD be encoded according to that same format." There is no discussion of what conditions would justify violating the SHOULD. Without this, many implementers treat SHOULD as MAY. My general rule is that every SHOULD must specify that alternative. =3D=3D>MT We have clarified by extending the second paragraph of Section 2.4 "Authent= ication Credentials" as below. OLD > The authentication credential of the Group Manager SHOULD be encoded acco= rding to that same format. NEW > The authentication credential of the Group Manager SHOULD be encoded acco= rding to that same format, in order to limit the number of formats that the= group members have to support and handle, unless it is infeasible or impra= ctical for the particular realization or instance of the Group Manager to h= ave an own authentication credential encoded in that same format. <=3D=3D 4) MINOR ISSUE Section 7.5 specifies External Signature Checkers. But I couldn't find any explanation of their purpose. I leave it to the authors to decide if there ought to be such an explanation. =3D=3D>MT We have expanded the first paragraph in Section 7.5 "External Signature Che= ckers" as below. OLD > When a message is protected in group mode, it is possible for designated = external signature checkers, e.g., intermediary gateways, to verify the cou= ntersignature of the message. NEW > When a message is protected in group mode, it is possible for designated = external signature checkers to verify the countersignature of the message. = For example, an external signature checker can be an intermediary gateway t= hat intercepts messages protected in group mode and ensures that they reach= the intended recipients only if it successfully verifies their countersign= atures. <=3D=3D 5) NIT The Abstract uses "CoAP" acronym without expansion. (Its defined in the Intro.) I think this isn't allowed in abstracts, which often stand alone. Please expand it in the abstract. =3D=3D>MT We have expanded the first sentence of the abstract as below. OLD This document defines the security protocol Group Object Security for Const= rained RESTful Environments (Group OSCORE), providing end-to-end security o= f CoAP messages exchanged between members of a group, e.g., sent over IP mu= lticast. NEW (emphasis mine) This document defines the security protocol Group Object Security for Const= rained RESTful Environments (Group OSCORE), providing end-to-end security o= f **messages exchanged with the Constrained Application Protocol (CoAP) bet= ween members of a group, e.g., sent over IP multicast.** <=3D=3D 6) NIT: Typo Section 3.3 says: "A. and then XOR with X bytes from the Common IV's start, where X is the length in bytes of the nonce." I think the above has a typo that can be fixed by s/A/4/ =3D=3D>MT We have changed "A." to "4." as suggested. <=3D=3D 7) NIT There is a minor grammatical mistake in section 4: s/was intended for./was intended./ =3D=3D>MT We have rephrased as below: > In such a case, the client assumes the response =91kid=92 to be the Recip= ient ID for the server for which the request protected in pairwise mode was= intended. <=3D=3D 8) NIT The IdNits tool reports a number of issues. Many are spurious, but there are several downrefs that should be evaluated. =3D=3D>MT The included references are as intended and deemed appropriate. Their under= standing and use are required by the present document in a normative way. Specifically as to RFC 5869, RFC 6979, RFC 7748, RFC 8032, and RFC 9053, th= ey are all listed in https://datatracker.ietf.org/doc/downref/ <=3D=3D --_000_GV3P280MB04506A5F81EB69EC160DC9349903AGV3P280MB0450SWEP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Paul,

Thanks a lot for your review! Please find in line below our detailed replie= s to your comments.

A Github PR where we have addressed your comments is available at [PR].

Unless any concern is raised, we plan to soon merge this PR (and the other = ones related to other received reviews) and to submit the result as version= -27 of the document.

Thanks,
/Marco



Marco Tiloca
Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se

From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Sent: Wednesday, July 23, 2025 8:44 PM
To: draft-ietf-core-oscore-groupcomm.all@ietf.org <draft-iet= f-core-oscore-groupcomm.all@ietf.org>; core@ietf.org <core@ietf.org&g= t;
Cc: General Area Review Team <gen-art@ietf.org>; last-cal= l@ietf.org <last-call@ietf.org>
Subject: Gen-ART Last Call review of draft-ietf-core-oscore-gro= upcomm-26
 
I am the assigned = Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://eur05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=3D05%7C02%7Cmarco.= tiloca%40ri.se%7C3dd8e3badbef4cc80d1208ddca18f3df%7C5a9809cf0bcb413a838a09e= cc40cc9e8%7C0%7C0%7C638888930715525949%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h= cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%= 3D%3D%7C0%7C%7C%7C&sdata=3Dep1ILkMDmoBAcnJg6v9qRG4ZhMCbIk0MdNr16Zy4cj4%= 3D&reserved=3D0>.

Document: draft-ietf-core-oscore-groupcomm-26
Reviewer: Paul Kyzivat
Review Date: 2025-07-23
IETF LC End Date: 2025-07-29
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the
review.

Comment:

This document notes "Readers are expected to be familiar with" (a=
daunting list of things). This was very challenging for a reviewer, who
is not. But I did read the whole document. I am incompetent to raise
issues about the essence of this document. Rather, I have focused on
more superficial aspects.

ISSUES: 4
NITS: 4

1) ISSUE

Section 2.6.2 says:

"If an implementation's integers support wrapping addition, the
implementation MUST treat the Sender Sequence Number space as exhausted
when a wrap-around is detected."

I think I understand the issue, but question how it is stated. Just
because the implementation does wrapping addition on integers shorter
than 40 bits, that doesn't mean the implementation isn't capable to
doing proper 40 bit arithmetic. There must be a better way to say this.
Perhaps:

"An implementation must treat the Sender Sequence Number space as
exhausted  when the Sender Sequence Number approaches the maximum valu= e
it can properly increment."

Also, if an implementation has difficulty handling 40 bit integers,
won't that also be a problem if it *receives* big sequence numbers?

=3D=3D>MT

Thanks for raising this detail. We have rephrased as below.

OLD
> If an implementation's integers support wrapping addition, the impleme= ntation MUST treat the Sender Sequence Number space as exhausted when a wra= p-around is detected.

NEW (emphasis mine)
> If an implementation's integers support wrapping addition, the impleme= ntation MUST treat the Sender Sequence Number space as exhausted when a wra= p-around is detected **upon incrementing the value that has been used as Pa= rtial IV**.

On the point raised in the last sentence of the comment, that's not suppose= d to be a problem. In the OSCORE option value, the Partial IV can be up to = 40 bits, hence a compliant recipient must be able to handle that if it happ= ens.

That's simpler than the case discussed above, since it does not involve ari= thmetic operations or other manipulation of the Partial IV value. It's just= about taking and using the Partial IV value as-is, in order to, e.g., perf= orm replay checks against a replay window (see Section 5.3), build an AEAD nonce (see Section 5.2 of RFC 8613= ), or build the external_aad for processing a message (see Section 3.4).

<=3D=3D

2) ISSUE

Section 6 says:

"An endpoint MUST be able to distinguish between a Security Context to=
process OSCORE messages ... and a Group OSCORE Security Context ... To
this end, an endpoint can take into account ... Alternatively,
implementations can ..."

Why offer alternatives? Why not specify a single unambiguous method?
If there is reason, it would be good to discuss the pros and cons.

=3D=3D>MT

We have updated the second paragraph of Section 6 "Message Reception&q= uot; as below.

OLD
> To this end, an endpoint can take into account the different structure= of the Security Context defined in Section 2, for example based on the pre= sence of Signature Algorithm and Pairwise Key Agreement Algorithm in the Co= mmon Context. Alternatively, implementations can use an additional parameter in the Security Context, to explicitly mar= k that it is intended for processing Group OSCORE messages.

NEW (emphasis mine)
**The way to accomplish this distinction is implementation specific. For ex= ample**, an endpoint can take into account the different structure of the S= ecurity Context defined in Section 2, **e.g.,** based on the presence of Si= gnature Algorithm and Pairwise Key Agreement Algorithm in the Common Context. **Alternatively, at the cost of= increasing storage**, implementations can use an additional parameter in t= he Security Context, to explicitly mark that it is intended for processing = Group OSCORE messages.

<=3D=3D

3) MINOR ISSUE

Section 2.4 says "The authentication credential of the Group Manager SHOULD be encoded according to that same format."

There is no discussion of what conditions would justify violating the
SHOULD. Without this, many implementers treat SHOULD as MAY. My general
rule is that every SHOULD must specify that alternative.

=3D=3D>MT

We have clarified by extending the second paragraph of Section 2.4 "= ;Authentication Credentials" as below.

OLD
> The authentication credential of the Group Manager SHOULD be encode= d according to that same format.

NEW
> The authentication credential of the Group Manager SHOULD be encode= d according to that same format, in order to limit the number of formats th= at the group members have to support and handle, unless it is infeasible or impractical for the particular realizat= ion or instance of the Group Manager to have an own authentication credenti= al encoded in that same format.

<=3D=3D

4) MINOR ISSUE

Section 7.5 specifies External Signature Checkers. But I couldn't find
any explanation of their purpose.

I leave it to the authors to decide if there ought to be such an
explanation.

=3D=3D>MT

We have expanded the first paragraph in Section 7.5 "External Signatur= e Checkers" as below.

OLD
> When a message is protected in group mode, it is possible for designat= ed external signature checkers, e.g., intermediary gateways, to verify the = countersignature of the message.

NEW
> When a message is protected in group mode, it is possible for designat= ed external signature checkers to verify the countersignature of the messag= e. For example, an external signature checker can be an intermediary gatewa= y that intercepts messages protected in group mode and ensures that they reach the intended recipients only if = it successfully verifies their countersignatures.

<=3D=3D

5) NIT

The Abstract uses "CoAP" acronym without expansion. (Its defined = in the
Intro.) I think this isn't allowed in abstracts, which often stand
alone. Please expand it in the abstract.

=3D=3D>MT

We have expanded the first sentence of the abstract as below.

OLD
This document defines the security protocol Group Object Security for Const= rained RESTful Environments (Group OSCORE), providing end-to-end security o= f CoAP messages exchanged between members of a group, e.g., sent over IP mu= lticast.

NEW (emphasis mine)
This document defines the security protocol Group Object Security for Const= rained RESTful Environments (Group OSCORE), providing end-to-end security o= f **messages exchanged with the Constrained Application Protocol (CoAP) bet= ween members of a group, e.g., sent over IP multicast.**

<=3D=3D

6) NIT: Typo

Section 3.3 says:

"A. and then XOR with X bytes from the Common IV's start, where X is t= he
length in bytes of the nonce."

I think the above has a typo that can be fixed by s/A/4/

=3D=3D>MT

We have changed "A." to "4." as suggested.

<=3D=3D

7) NIT

There is a minor grammatical mistake in section 4:

s/was intended for./was intended./

=3D=3D>MT

We have rephrased as below:

> In such a case, the client assumes the response =91kid=92 to be the Re= cipient ID for the server for which the request protected in pairwise mode = was intended.

<=3D=3D

8) NIT

The IdNits tool reports a number of issues. Many are spurious, but there are several downrefs that should be evaluated.

=3D=3D>MT

The included references are as intended and deemed appropriate. Their under= standing and use are required by the present document in a normative way.

Specifically as to RFC 5869, RFC 6979, RFC 7748, RFC 8032, and RFC 9053, th= ey are all listed in https://datatracker.i= etf.org/doc/downref/

<=3D=3D

--_000_GV3P280MB04506A5F81EB69EC160DC9349903AGV3P280MB0450SWEP_--