Return-Path: X-Original-To: core@mail2.ietf.org Delivered-To: core@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C29FF9CBCE86; Thu, 18 Dec 2025 23:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 uTn3WtysG2WB; Thu, 18 Dec 2025 23:07:43 -0800 (PST) Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.238]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9BC869CBCE76; Thu, 18 Dec 2025 23:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1766128063; x=1797664063; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=eZ6ipnaEhSHY9lxOt8l+AKdF2pl2Y+fxM5HGzkzHeQI=; b=r5c2xdAwWM7awOS9Pv7GoVMrm4YI/BDtRiRdBgv2NtWf24ZmyPvaXe1I 5OVhdusader9y/fvK5vInqGihbLIn3iToTDO8MMOdPezC2UDjOQ0Z0cN9 TTuzRvIc2wlpzKPhofr6YpToe6CWnBFsR5druWyMGQCfWJo/LzBaT+1G6 zJZiFS+WrA3sUVqf3QMzJScTnDtippENJ5EUtTvtd5sbG6irYZB41gfZR amiAzbAoz5lf9HTW+pd7dCwLai766IOoxgr/dsnVhlBDawv5spXQvq6wR q74M3JRQmwjLTIVq9j8dRPq6qOmOLlDiNws7pgKIENhoR7e6OkEu3+ZST A==; X-CSE-ConnectionGUID: 0jcodo19QTOgIev7WM3cZw== X-CSE-MsgGUID: SiOT56yFSgaIoRf+XZQqQg== Received: from unknown (HELO opfedv1rlp0h.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 19 Dec 2025 08:07:41 +0100 Received: from unknown (HELO opzinddimail16.si.fr.intraorange) ([x.x.x.x]) by opfedv1rlp0h.nor.fr.ftgroup with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 19 Dec 2025 08:07:41 +0100 Received: from opzinddimail16.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id 3B59ADE08E9; Fri, 19 Dec 2025 08:07:41 +0100 (CET) Received: from opzinddimail16.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 5F673D641B2; Fri, 19 Dec 2025 08:05:04 +0100 (CET) Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail16.si.fr.intraorange (Postfix) with ESMTPS; Fri, 19 Dec 2025 08:05:04 +0100 (CET) Received: from mail-francecentralazlp17012050.outbound.protection.outlook.com (HELO PR0P264CU014.outbound.protection.outlook.com) ([40.93.76.50]) by smtp-out365.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 19 Dec 2025 08:05:04 +0100 Received: from PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:52c::5) by PASP264MB4744.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:432::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9434.9; Fri, 19 Dec 2025 07:05:02 +0000 Received: from PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM ([fe80::8b83:578b:5221:8deb]) by PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM ([fe80::8b83:578b:5221:8deb%3]) with mapi id 15.20.9434.009; Fri, 19 Dec 2025 07:05:02 +0000 From: mohamed.boucadair@orange.com X-CSE-ConnectionGUID: r2wNynwLQU+8TcVETAhU4g== X-CSE-MsgGUID: DHABwU3DRvSyRtBJzMXskg== X-TM-AS-ERS: 10.218.35.132-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-DDEI-TLS-USAGE: Used X-CSE-ConnectionGUID: rANqT6bOR76vsBak3h36Hw== X-CSE-MsgGUID: 7e8vIBsHQJeS4ChKVvxYRw== Authentication-Results: smtp-in365b.orange.com; dkim=none (message not signed) header.i=none IronPort-Data: A9a23:VAeTn66JpGnom6feLY6XqgxRtKrHchMFZxGqfqrLsTDasY5as4F+v jFMDT+GOazbMWvxfI0nPIm+80gAupbTn9BnTANpry9nEysa+MHIO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG/6yE6j+fRH+CU5NfsYkhZXRVjRDoqlSVtkus4hp8AqdWiCmthg /uqyyHkEAHjgWcc3l48sfrZ9Uo15aWq4Vv0g3RlDRx1lA6H/5UqJMJHTU2BByOQapVZGOe8W 9HCwNmRlkvF/w0gA8+Sib3ydEsHWNb6ZWBiXVIPBsBOKjAbzsAD+v5T2Mg0MC+7uB3Q9zxF8 +ihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCAWluVbD09NqbDklU3 NoBFG4HSSrc2fyt6ru4Eek32OQ8eZyD0IM34hmMzBnhN64eG86faJiSvIMe2yosjMdTG/qYf 9AedTdkcBXHZVtIJ0sTD5U92uyvgxETcRUE8BTE/uxovS6OlGSd05C1WDbRUtmNRcxQk0rer GXb9G31CxAAHNuFwDyK/zSngeqncSbTAdtKSuDpqaQ06LGV7jMeWAM3f0CbmNu0sRKVW/FhN VwlwDV7+MDe82TwFYOhAHVUukWsuxcGUN0WD+w+7wqEn/aM+QffHWUsQjtIctdgtcIqS3otz FDht9LkHjNHsbCJRzSa7Lj8hT+oMCYJaG4PeSFBRgwf7pzku4o0lB+KQcxkDba+idjwMTD93 z7MqzIx750YitQGkq679FHdmBqtq4THCAkv6W3/VWW/4yt4aZKrIYuy5jDz5vZaLZ2FT1CHl HEBgNWT9/tIBpaI/BFhW80IFbCtovifOTvXjFViGYU7/jCk6Xq7JN8IuWsmeR8vNdsYczj0Z kOVoRlW+JJYIHqta+lwfp61DMMpi6PnELwJS8w4cPJUS75oSFGN2xsxO1CL9Wnuy0h3z4Egb MLzndmXMZoMNUhw5BSML9rxPJcuzyE6gG3JTJbwwh+q16aEbXqcW7MdaQTWN7phsfvCpxjJ+ dFCMcfM0w9YTOD1fijQ98gUMEwOKn84Q5vxrqS7l9JvwCI5RAnN6NeIm9vNnrCJeYwJzo8kG VnmCydlJKLX3yGvFOlzQikLhEnTsWlDQYITZnd2YQnAN4kLZIek9qAEcJUrNbIg7vQL8MOYu 8ItIp3aatwWE2yv021EMfHV8tY+HDz13ljmF3T+P1ACk2tIG1ahFinMIlG3rHFm4+venZdWn oBMISuHG8BaF108XJq+hTDG5wrZgEXxUdlaByPgSuS/sm22mGS2A0QdVsMKHvw= IronPort-HdrOrdr: A9a23:gSFTiapBdGZMPxeVUrYxIloaV5ugL9V00zEX/kB9WHVpm5Oj+v xGzc5w6farsl0ssSkb6Ki90KnpexPhHO1OkPIs1NaZLUHbUQSTXeVfBOfZrQEIXheOj9K1tp 0QOJSWaueAamSS5PySiGXWLz9j+qjgzEnCv5a8854Zd3AOV0gW1XYaNu/0KCxLbTgDIaB8OI uX58JBqTblU28QdN6HCn4MWPWGj8HXlbr9CCR2SiIP2U2rt3eF+bT6Gx+X0lM1SDVU24ov9m DDjkjQ+rijifem0RXRvlWjo6i+2eGRheerNvb8y/T9GQ+cyjpAo74RGIFqiQpF7t1HLmxa0u Uk7S1QeviboEmhBF1d6SGdpjUIlgxeoUMKgGXo/kcKraHCNU4HItsEioRDfhTD7U08+Nl6za JQxmqc84FaFBXagU3Glq/1vjxR5z+JSEAZ4Joupm0aVZFbZK5arIQZ8k8QGJAcHDji4IRiFO V1FsnT6PtfbFvfNhnizyBS6c3pWm52EgaNQ0AEtMDQ2z9KnGphx09dwMAEhH8P+J80VpEB7e XZNaZjkq1IU6YtHNRALfZERdHyBn3GQBrKPm7XKVP7FLsfM3aIsJLz6KVd3pDZRHXJ9upApH 3saiIpiYdpQTORNSSn5uw7zizw X-Talos-CUID: 9a23:W5NG5mOoV+8rme5DQgBB7XJKEOcfLSPD113ZIBS4UjhJV+jA X-Talos-MUID: 9a23:cQKCCQnd9p5BrJsrhno1dno9OZd2wo61KHkvnK5akMmnCzJgCg2C2WE= X-IronPort-AV: E=Sophos;i="6.21,159,1763420400"; d="scan'208,217";a="110659726" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FLBl5Uthin2TNQMPZWVHziUFEu3949AwkSlrI1SsjDp7EFmi9uCwjjUYSyrvjkrqouXaW6Jf0WL9fJT2YXmAEkAXENXFXcpXLTZ1SsiyHCPwb1aopomQ50DxWUaTphpkZQke6GxxYdTG62f5ihO2YLi0LsWPTyQPDFFLZxygwZa3KuumuhYCq7mfp/fzg9HBAcGlQi7GNgeEnmN7j5xEPTShi4JX/U4C+RHRnXMmyvnNa7QqLpk/yUC4cwnF2CzA8vqflGNkZgC1PWP4GOtm9sgWpoRIPMMR3eOHq5QLKRYjYgdup9/PEPS9U0mV4rQ0onRyUJyoG5StmT7qs8tjpQ== 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=dLMkgVUU9jDrRVtTTEsdQaL/n3bi9jvrngGQErXJMyc=; b=DrEg4QbUcH3bb+OTlTnBH7cWhs4IEsjd/rIBXj3VkveiukdQVPkq6MuSkxGkCoItoNu/o5Xqy02v5csJxkkXXBOwCc8L+H6edFcSXhyElBFKPuJYfblG7iXie6NQU2Xx/FH3x/ggiQN51j++7RapFF8xuQlRF3QfI+ViJ1e0C8BMURjm4HWtibesCxOBdwGgvCEyvVGfqfn2VrVeu7eUf3PrrHfvdKjKP4E5k0Vxy2HzichBjgERTEkoWBqFsTlaTsrBS9RDzjyvztRMasRMsZ7Zos/fuAI7hprbH1C2fCGCDtnmr1otF/s/cwcxij1+/Mu9AD5x6gGQ/Jq5ZWEjAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none To: Marco Tiloca , The IESG Thread-Topic: Mohamed Boucadair's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT) Thread-Index: AQHcN5NHOf25uaLej0C4oD0o4jQ7D7UeuG0ogApDLpA= Date: Fri, 19 Dec 2025 07:05:02 +0000 Message-ID: References: <175984585755.4038373.14177717915958278962@dt-datatracker-6c6cdf7f94-h6rnn> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=218c0d34-afba-4fee-9ec6-2b77dd5b28f2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2025-12-19T07:02:15Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Tag=10, 0, 1, 1;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_ContentBits=1;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_Enabled=true;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_Method=Standard;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_Name=K2 Intern;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_SetDate=2025-12-12T18:27:23.900Z;MSIP_Label_680afd86-dcf7-4483-b9eb-5af1dcd104e1_SiteId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PAUP264MB6756:EE_|PASP264MB4744:EE_ x-ms-office365-filtering-correlation-id: 1ef8e886-7e70-4acd-25d1-08de3eccee49 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021|8096899003|13003099007|7053199007; x-microsoft-antispam-message-info: =?iso-8859-1?Q?9gIwxNVHrYiTMAdwnDPj4fdN9k2K0ZQArqUYTs/CJrb9GsLd1RHQnounlh?= =?iso-8859-1?Q?Jpyh7sWIPKYK3xNiOOxVx81FsKsSpqQiUdgW5h4z0sEalbumHyfABupHZa?= =?iso-8859-1?Q?6fcN2zrbFCqG32mRiYMeaVl71YwEPqjAiL2SnqJolWw922oJvjMHNZyMZr?= =?iso-8859-1?Q?rbueB+01b79pbO4llKYw+JjWHtg1H7fcJLijFq9moyasjYKfTh4OjY+Sm3?= =?iso-8859-1?Q?eRvCi8UBap5X8b/IirJftVRPWn2zbiqYlNvg7A4NWbTxjFgsjOB3cKyjA5?= =?iso-8859-1?Q?TdKNzw8yOSbrx+Wm4dueIxADnoNm62VOUxc1I/1r+44bowG6Y3UWRhEOQG?= =?iso-8859-1?Q?Zbm9vBbdaTqWD/HDrHWC40bYYNxOyjJdu5iy2bGFsbFqb7aYwZIbJIzq9u?= =?iso-8859-1?Q?kDNjzCn2H5nwK8e6LxL7l5510svEXV9AtqrTWMdKacu82VzbghbTv/Trnd?= =?iso-8859-1?Q?8Vl27dO3/+InMZ7NEbRsUxVjF6RlTvLlqzCoigJIRjQz+MnsvEznaaonWy?= =?iso-8859-1?Q?0RtVxBHZ6W5IHdiBWxHRmaendcEF26dWkiDCGJ6MiL4IDNorEs5ye2UhhA?= =?iso-8859-1?Q?rIW6jRqf1UCOUdmVRS5GuiC2zr+Xth2WoxQg9w/t+j6IOj5iR8n+WWw937?= =?iso-8859-1?Q?pLdOa6UR8Az+iS8e+EIy33uRr+c6Ey56X7FTYhj1229dV8ThN4NQypKmrg?= =?iso-8859-1?Q?ADgpZfhhcsB8VISglLvK7XygBhJUnaD9Xe9BD6E6SMgX9wE3sB5KvTSo2j?= =?iso-8859-1?Q?ZfX6pqFgriIak51VJbwPhWwmPgom4qHZX0VdyONAEMu4a/0kQ0ER7ZeqHx?= =?iso-8859-1?Q?32nVpapE9bruXJbAVJjJkz5jKrRO4D+WRxvcn1ZpzF+/82D5jUTZ3tW8Ah?= =?iso-8859-1?Q?9RYAEkqlN7TVCw0DEd7QYw+E1aaOdsfWZQB1Fr86/z9MI4LarilEwYN/gP?= =?iso-8859-1?Q?chARXFVYCAgi2NCWQjaNCeL8FyE8Dsr10+djbpYFHiy6GxEk/DGAKC6Wkq?= =?iso-8859-1?Q?waBg7ooJCwL06bWmtup2JGsUEa6kci6LIWXymafcJzXRddVltbYSfWCAs6?= =?iso-8859-1?Q?qP6E4KJnRD7iJpxZab7NvwYziUQicIBJD79rYfaCRdpmYx6AMsWRwsRtlF?= =?iso-8859-1?Q?mM08FipcGdSADk6MPQ6FvvL2p2eFS4lc8ekZyGdWCz5mkeOkIkXqli3Ied?= =?iso-8859-1?Q?gHroYxRvQ21YUoceN+0h+z6f3JrmC2XHm38pq1VQEgHnCoVtUOx0xOdWyA?= =?iso-8859-1?Q?S8S9GfjUzVtuL47CbmakMvEzc9yoEuzxFLFIyM+8M603uLuJdViEiNVBS1?= =?iso-8859-1?Q?MZReAMwlk0+DjSfmirEYHFhF5Wf8zPCXUeug2CVJbmwyk6Dc7tsEdB9Qs8?= =?iso-8859-1?Q?G+dCmJxMm+sPboD/sDgrshnC6hk7j829CLu2/FLm3l8Nmz4GdPAyvPbINv?= =?iso-8859-1?Q?0QM2PVDnp1QuQULfLRB9G65S30njBcM6B20caZ81jdbp/Jd6OONBEfqA4f?= =?iso-8859-1?Q?5rOKamk1dgmX2fncHS3lPfBtzRHEaEfbSQJxB23Pv6LV85412ataF3kPH/?= =?iso-8859-1?Q?/KVUmNsRnfoBqOKWdFxCG1O6j5Oo32r7SlloRrEWYp/YKZMHSA=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021)(8096899003)(13003099007)(7053199007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?55jypCHy8OOF/9U3pg1xSp1BuwY8XYyaGysPKZtD8xy6cLSJv4DZRxuZU8?= =?iso-8859-1?Q?cmqoM/Uk+gocKZv2LwPOJTyRvzPf5qlPaZZXAGsiK+iWYGgo5Pm+VmR2vN?= =?iso-8859-1?Q?/IunN1lfKvEqLDwaIRILXqGA1iafsgZSzA20/DuRnV49svMHsjf3VhPO6a?= =?iso-8859-1?Q?WKng8eu5VR2MWfyGPlBGiXGn1hXdtrx0pgeVETPeoF8o1hMmA/ja+ndsDY?= =?iso-8859-1?Q?AqyTQuTYi/CWiWda064JviqEvrX5Uf+LG4R/EAP737IAp7z5CVs7L+vKxd?= =?iso-8859-1?Q?OHwbARbKFD9LjgDhI/8vpRfu1KvOSD0zbyxLYurYrAG2CKzMh1D+folIBZ?= =?iso-8859-1?Q?SiYHb1oBFktwX83h3zQBQ4yot3Z/fcaWlGVtDXw47Lv3ImFcHHoJToi8gB?= =?iso-8859-1?Q?3zJtgMqKw0Rs1hpVNjX6o0RCHOcrCIFMnOaQYTZ6TZEl14o3HW5Yo0rq8D?= =?iso-8859-1?Q?+nkLGrLKhep1jBEupJgNKrijDNJchb1SqPIbQcI+YCTT1fmrdx/h+YoueC?= =?iso-8859-1?Q?c66IJ03RG+K/DPuxK0LrPo2j5iZekWWCPL2XsCrvQQRQVoCAM3wDjQ99uo?= =?iso-8859-1?Q?coolfk5pxMIVXTWMHBuQT60h/ub8jjDV9me0fCAwiiGgHBwS1tuIuhBJ2T?= =?iso-8859-1?Q?ymMNJ69QAOjumuLPZ5sshG76yIklsnrwBhQhXCj41SvBRqpuHLSCFmVhH3?= =?iso-8859-1?Q?WnUZsTgxahl3Y/eFZbLihmlN2TtTbQl3qRunSmT2goq9HiB8GvfQZvZ6Og?= =?iso-8859-1?Q?VolA3pJ7V370NQmPCHspoUr+LAW+Wi0gO1sF8DFRlWQD2sfJGLERx1oSfx?= =?iso-8859-1?Q?k5vhVNqlVFpt6v4Tm4L3yto8xozttyc1w9Odb95UF5MNOlkDCTJ4QcCZ7O?= =?iso-8859-1?Q?qvVj6UHIjxJSdpmXJ8bn/Iv38eFK2WSTwDMlsL75gXZvnl3OD27X97RTlP?= =?iso-8859-1?Q?XX/TrOvbSI0bkKgcANqHztPC1ujsZojEmAt1iABrx8qJ46k5WE2pt6Alcb?= =?iso-8859-1?Q?G+DcfIEF7VRp+I+/gEVlkU387DJLnzIORErRDEb/nD/gceCFX1xfnRWnnQ?= =?iso-8859-1?Q?fOrYTgDULysUJ31uIiN55ZQjPrQIvp3NbnnBrkr7GJmP+ibXrVcOWetFVr?= =?iso-8859-1?Q?rSQGuYcooQizUOLoL+SDg8Oc2gpli6fBwpKZnvMR7tlgYJOa7IzZJoVGps?= =?iso-8859-1?Q?fSXjTZYZ/HLBBjCdrK5hyLPGK/IzEDGtzHrGntiPuAtx58PtpxQZP9cQIG?= =?iso-8859-1?Q?rRpVYT9kBqQBKVnLcPs1ZqHeTT/nszT78YNnL30WXvZSJOe8FRg4Olqi0U?= =?iso-8859-1?Q?sxaDzjWU6FNCkR9mvgOcMJkU04vg/kRIv73ELyya5uHS7rggvwVJSNdGAo?= =?iso-8859-1?Q?1RFo3X8M6m9KxBemtnutgINVbxf78Sm0s6TNTiYGM6xJ+06Vsb8emznPVP?= =?iso-8859-1?Q?Gf5Yhd/jfdL5LoPaQmnTRIV3nwUbudl4fhrxJXeNYtVRbrModyrBqnmh5Y?= =?iso-8859-1?Q?vtXo1g4WvpN+285/UeABVjzHhq7UvrnxQ0sN/soSpYrATSqJFvPj3kfm0q?= =?iso-8859-1?Q?elhE4lNS9gF6XAtwPaxSnfW3KnGBviShVQkCc/mZR4MbwtuEl/lNAyWZtK?= =?iso-8859-1?Q?5NpJJSfudsENKoh7CnPl6gccx2IYRGauo2FXi55KLhlfaZs/9K6hrgnw?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PAUP264MB67561968BF7F97043352437388A9APAUP264MB6756FRAP_" MIME-Version: 1.0 X-OriginatorOrg: orange.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1ef8e886-7e70-4acd-25d1-08de3eccee49 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2025 07:05:02.5108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BFSa5Uy/49r/B0VWUBT8jLNpzH1f+aQKxdA4LOPygZuMjU916Xeu4tsSKK8hz01qFuE3o089Yt7eKPy2WNPYl46jv3jV+FiLjFjvrGOQaDU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PASP264MB4744 X-TM-AS-ERS: 10.218.35.132-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-TMASE-Version: DDEI-5.1-9.1.1004-29644.005 X-TMASE-Result: 10--33.538600-10.000000 X-TMASE-MatchedRID: apYFl0ey1oo0VDVFBNavIy6zy4yySgXEnEwQ8IYl7MS8iX8opkmgzwmG bpOMTi81DZs/KgmqdktvTi4hBnJxzQFyn90r0pFoy/SydI98ZamHIhFGaFX5NJRBa3u5J+EMXlJ qiTX99kJBDn6Fjq77jjoSfZud5+GgvDGpIrQZI9H2TbfgokMDhSRc6Tw54+0uKWjAFuqZT3hpvK sH78j7+De9MF4SNA1+V2y0V2O63Z5i4CtQ35BnJLphj8rLEzG1Awr1d1MD+ngJ0s0WLmuOQD8hX NK+3FBhRHSgjCgw/JULwteD+QnyUGwDduV1zUUUGmVudEhnpoQvcgUibwrcmmB7doPBjWYu8ZTi bkDR5X21PiMh4ZF39SjhvSkr09hAFXXsIV9lgAEAuwGUpXiTDbVAJvqo6KX0XvLGzGhYHB+QChJ gCUVPzxmiTJb38WReT5ysQDj6eFnqWOQST6GEB8IrJyGzvIdDv054pCpXX9cWqBWfdqyo/h2mQZ VcW1xaBe3KRVyu+k2oP1ciLAYAhlgLks93sG9tXxIDqJ6h43eXE+xHCJjkvPFjAM4L4KUOKZmZV TSm7/nZJrfdkZdZ1hA5wxKjT3bqYAEYUXhXMUdxUTGe37bsoz2uSi5Lssr5275BbjTDINj2N0hu HT3B5/HkpkyUphL9VBDQSDMig9EgUEQTkIWiYmMLQxo49FU91Mt1ncO1B/Bjdusq9iO0QbvSbVu ACOHyxzNaeDaFsoOlY4F8r0vXPx9oEkuuWUr1jD2Ays6R/rTw2sXPeilV9d351eV+3mgb0k5Xcx iCLD6HgJ7XaDMQWgGo1vhC/pWj96Ahwxtb7c7dlak27ZJzYX7vQbj1Rh/zlxnSJwunsOofE8yM4 pjsDxM0JxSxHjFJTDXDVo1TfPgWSht/Q8exDbXwHj/AmsmGJSJYhAqSM95eEwvCM9Wp+V1FkXVL +ky7tT4piLWpY7p+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 4a53d111-adb9-4405-9233-4db061b8d396-0-0-200-0 Message-ID-Hash: BUWJ6CQVGT57CAZTQ7UZA2I4GFMRIBSV X-Message-ID-Hash: BUWJ6CQVGT57CAZTQ7UZA2I4GFMRIBSV X-MailFrom: mohamed.boucadair@orange.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-core-oscore-groupcomm@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "christian@amsuess.com" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bcore=5D_Re=3A_Mohamed_Boucadair=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?core-oscore-groupcomm-27=3A_=28with_COMMENT=29?= List-Id: "Constrained RESTful Environments (CoRE) Working Group list" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_PAUP264MB67561968BF7F97043352437388A9APAUP264MB6756FRAP_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Marco, Thank you for the follow-up and detailed reply. Looks good to me. I reviewed and approved the PR right now. Cheers, Med De : Marco Tiloca Envoy=E9 : vendredi 12 d=E9cembre 2025 19:27 =C0 : The IESG ; BOUCADAIR Mohamed INNOV/NET Cc : draft-ietf-core-oscore-groupcomm@ietf.org; core-chairs@ietf.org; core@= ietf.org; christian@amsuess.com Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-core-oscore-grou= pcomm-27: (with COMMENT) Hello Mohamed, 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= -28 of the document. Thanks, /Marco [PR] https://github.com/core-wg/oscore-groupcomm/pull/122 ________________________________ From: Mohamed Boucadair via Datatracker > Sent: Tuesday, October 7, 2025 4:04 PM To: The IESG > Cc: draft-ietf-core-oscore-groupcomm@ietf.org >; core-chairs@ietf.org >; core@i= etf.org >; christ= ian@amsuess.com >; christian@amsuess.com > Subject: Mohamed Boucadair's No Objection on draft-ietf-core-oscore-groupco= mm-27: (with COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-core-oscore-groupcomm-27: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://eur05.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballo= t-positions%2F&data=3D05%7C02%7Cmarco.tiloca%40ri.se%7Ccb9508054ed14fcef77a= 08de05aa6879%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63895442661939803= 3%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiO= iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D1FkxhoZAcp= XWT2ttIsAnJ6I7bRab3NTIhGUKMzJb8CE%3D&reserved=3D0 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://eur05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-groupcomm%2F&data=3D05%7C02%7C= marco.tiloca%40ri.se%7Ccb9508054ed14fcef77a08de05aa6879%7C5a9809cf0bcb413a8= 38a09ecc40cc9e8%7C0%7C0%7C638954426619423444%7CUnknown%7CTWFpbGZsb3d8eyJFbX= B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI= joyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DuTm9wYR3yd20VE%2FUUbtXjoIbIl2ZdZiyGaLRbpb0= o8s%3D&reserved=3D0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Marco, G=F6ran, Francesca, John, and Rikard, Thanks for the effort put into this spec. I appreciate the discussion in Section 12, in particular. Please find below some comments: # Re-keying & Observe CURRENT: * Long exchange: an exchange of messages associated with a request that is a group request and/or an Observe request [RFC7641]. I wonder whether there any impact of key change on installed observed. =3D=3D>MT By design, there is no impact, except for a very specific case that is deta= iled below. As to the general case, Section 3.4 "Additional Authenticated Data" explain= s that the new element 'request_kid_context' in the aad_array achieves prec= isely the seamless and safe preservation of active long exchanges (includin= g observations), also after a group rekeying has occurred. As to the particular case, a group member might be evicted from the group p= recisely to prevent by construction that any long exchanges can remain acti= ve unsafely. This concerns a particular, delicate situation that can arise during the li= fetime of a group and throughout instances of group rekeying, if the Group = Manager is configured to reassign Gid values as defined in Section 12.2.1.1= .1. In such a case, in the interest of safely preserving long exchanges, the Gr= oup Manager has to additionally store the "Birth Gid" of each group member,= i.e., the Gid that was provided to that member at its latest group (re-)jo= ining. When rekeying the group and thereby establishing a new Gid value, the Group= Manager must determine whether there are "elder" group members whose assoc= iated "Birth Gid" is equal to the new Gid to establish. If that is the case= , then the group rekeying has to effectively evict from the group also such= group members. Consequently, as stated at the end of Section 12.2.1.1.1: * Excluded elder members could eventually re-join the group, thus terminati= ng any of their ongoing long exchanges (including observations). * It is ensured by construction that there cannot be long exchanges that ar= e active unsafely. That is, it is ensured that no client can have with the = same server two ongoing long exchanges, such that the two respective reques= ts were protected using the same Partial IV, Gid, and Sender ID. <=3D=3D # To whom? CURRENT: How the Security Context is established by the group members is out of scope for this document, but if there is more than one Security Context applicable to a message, then the endpoints MUST be able to ^^^^^^^^^^ tell which Security Context was latest established. ^^^^^^ =3D=3D>MT We have rephrased as below, to have the intended meaning explicit. OLD > ... then the endpoints MUST be able to tell which Security Context was la= test established. NEW (emphasis mine) > ... then the endpoints MUST be able to **determine** which Security Conte= xt was latest established. <=3D=3D # Capability CURRENT: An endpoint of the group may use the group mode (see Section 7), the pairwise mode (see Section 8), or both, depending on the modes it supports and on the parameters of the Security Context. Is there a need to know in advance with a remote endpoint supports one or a= ll these modes? Does that have impact on how contexts are established? =3D=3D>MT The short, practical answer is "no" to both questions. There is intentionally a separation between, on one hand, what modes are "e= nabled to be used" in the group according to the decision of the Group Mana= ger, and, on the other hand, what modes an individual group member supports. The establishment of the Security Context is largely based on the informati= on and parameters obtained from the Group Manager. That's sufficient to ind= icate whether one mode, or the other mode, or both are "enabled to be used"= in the group. Consequently: * A group member supporting a mode will be effectively able to use that mod= e, if that mode is enabled to be used in the group. * A group member (irrespective of what it supports) knows about the mode(s)= that are enabled to be used in the group, while it does not know what anot= her group member supports until communicating with that other group member. If the use of the pairwise mode is not enabled in the group and/or a group = member does not support the pairwise mode, then that group member does not = install: * Pairwise Sender Keys for the other endpoints, in its own Sender Context. * The Pairwise Recipient Key for any other endpoint, in its own Recipient C= ontext corresponding to that other endpoint. The above is highlighted in Figure 1 of Section 2. Similarly, other paramet= ers in the Common Context are not relevant to install if they pertain to a = mode that is not enabled to be used in the group and/or that the endpoint d= oes not support. <=3D=3D # How the limit is know? Can that be retrieved from the system and exposed = to the app? CURRENT: An endpoint may admit a maximum number of Recipient Contexts for a same Security Context, e.g., due to memory limitations. After reaching that limit, the endpoint has to delete a current Recipient Context to install a new one (see Section 2.6.1.2). It is up to the application to define policies for Recipient Contexts to delete. =3D=3D>MT It's not that the maximum number can be "retrieved from the system and expo= sed to the app". Like stated later in Section 2.6.1.2, "Group OSCORE in itself does not esta= blish a maximum number of Recipient Contexts". In fact, the application is also meant to define that maximum number, toget= her with the policies about deleting Recipient Contexts. We have rephrased and improved the last sentence as below: OLD > It is up to the application to define policies for Recipient Contexts to = delete. NEW (emphasis mine) It is up to the application to define **the maximum number of Recipient Con= texts for a same Security Context as well as policies for deleting** Recipi= ent Contexts. <=3D=3D # Tracking/Logging CURRENT: The Security Context may contain a large and variable number of Recipient Contexts. While Group OSCORE in itself does not establish a maximum number of Recipient Contexts, there are circumstances by which implementations might choose to discard Recipient Contexts or have to do so in accordance with enforced application policies. Such circumstances include the need to reclaim memory or other resources on the node hosting the endpoint, for example because the predefined maximum number of Recipient Contexts has been reached in the Security Context (see Section 2.2). How these discarded contexts are tracked? Are there some king of alarm/notification to warn this? =3D=3D>MT They are not tracked and Group OSCORE in itself does not need to specifical= ly track/log their deletion. Group OSCORE in itself only needs to switch into initializing the Replay Wi= ndow of new Recipient Contexts as invalid, if those are created after the f= irst deliberate deletion of a Recipient Context (see third paragraph in Sec= tion 2.6.1.2). If an endpoint N_1 deletes a Recipient Context associated with another endp= oint N_2, then N1 will be later able to create a new Recipient Context asso= ciated with N_2, when receiving a message from N_2 (just like it did the fi= rst time). Since the application might have some interest in logging these deletions, = we have extended the text as follows. NEW (emphasis mine) > Such circumstances include ..., for example because the predefined maximu= m number of Recipient Contexts has been reached in the Security Context (se= e Section 2.2). **Implementations can provide means for the application to = gain knowledge about the deliberate deletion of Recipient Contexts, e.g., t= hrough notifications sent to the application and/or logs made available to = the application.** <=3D=3D # Is there a reason what the Group Manager may not be informed? Shouldn't s= uch event be logged locally, btw? Shouldn't the manager be contacted prior to exhaustion and not wait for full exhaustion? CURRENT: Upon exhausting the Sender Sequence Number space, the endpoint MUST NOT use this Security Context to protect further messages including a Partial IV. When approaching the exhaustion of the Sender Sequence Number space, the endpoint SHOULD inform the Group Manager, retrieve new Security Context parameters from the Group Manager (see Section 2.6.3), and use them to derive a new Sender Context (see Section 2.2). =3D=3D>MT Addressing the three questions in order: **1.** Is there a reason what the Group Manager may not be informed? There is no particular reason to inform the Group Manager specifically abou= t that. In principle, the endpoint in question can also live with the situation saf= e and well, as long as it is not going to consume new values of its Sender = Sequence Number. This is the case, e.g., if the endpoint plans to not send = any message at all for a long while, or only to send first-responses to a g= iven request (which do not need to consume a Sender Sequence Number). In order to start over with new keying material and Sender Sequence Number = 0, indeed an interaction with the Group Manager is required. That interacti= on is specifically a request to re-join the group or for only obtaining a n= ew Sender ID, and it abstracts away from the particular underlying reason. **2.** Shouldn't such event be logged locally, btw? We don't see any particular reason or advantage in doing that. **3.** Shouldn't the manager be contacted prior to exhaustion and not wait = for full exhaustion? Indeed. This is what the fourth paragraph in the same Section 2.6.2 already= says after the quoted text above, i.e.: > It is RECOMMENDED that the endpoint takes this course of action with some= margin, i.e., well before exhausting the Sender Sequence Number space, in = order to avoid a period of inability to protect messages including a Partia= l IV. <=3D=3D # Not new behavior: cite as quote OLD: As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent over multicast MUST be Non-confirmable, and thus are not retransmitted by the CoAP messaging layer. NEW: As per [RFC7252][I-D.ietf-core-groupcomm-bis], "group requests sent over multicast MUST be Non-confirmable", and thus are not retransmitted by the CoAP messaging layer. And OLD: According to Section 5.2.3 of [RFC7252], responses to Non-confirmable group requests SHOULD also be Non-confirmable, NEW: According to Section 5.2.3 of [RFC7252], "responses to Non-confirmable group requests SHOULD also be Non-confirmable", =3D=3D>MT Let's take the two suggestions separately. **On the first suggestion**, there is no single, common sentence that we ca= n quote verbatim from those two documents. The closest sentences that they = have are: In RFC 7252 * Section 8.1, "Such multicast requests MUST be Non-confirmable." In draft-ietf-core-groupcomm-bis * Section 3.1.1, "All CoAP requests that are sent via IP multicast MUST be = Non-confirmable (NON)". * Section 3.6, "An IP multicast request MUST be Non-confirmable (Section 8.= 1 of [RFC7252])." Instead, we have rephrased as below to simply state a fact, without restati= ng through normative language, i.e.: NEW (emphasis mine) > As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent over m= ulticast **are always** Non-confirmable, and thus are not retransmitted by = the CoAP messaging layer. **On the second suggestion**, that works but we have to use (part of) the s= entence from RFC 7252 verbatim, i.e.: > If the request message is Non-confirmable, then the response SHOULD be re= turned in a Non-confirmable message as well. However, an endpoint MUST be p= repared to receive a Non-confirmable response (preceded or followed by an E= mpty Acknowledgement message) in reply to a Confirmable request, or a Confi= rmable response in reply to a Non-confirmable request. So we have extended our text as below. OLD > According to Section 5.2.3 of [RFC7252], responses to Non-confirmable gro= up requests SHOULD also be Non-confirmable, but endpoints MUST be prepared = to receive Confirmable responses in reply to a Non-confirmable group reques= t. NEW (emphasis mine) > According to Section 5.2.3 of [RFC7252], **"[i]f the request message is N= on-confirmable, then the response SHOULD be returned in a Non-confirmable m= essage as well. However, an endpoint MUST be prepared to receive (...) a Co= nfirmable response in reply to a Non-confirmable request."** <=3D=3D Cheers, Med ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_PAUP264MB67561968BF7F97043352437388A9APAUP264MB6756FRAP_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Marco,

 

Thank you for th= e follow-up and detailed reply.

 

Looks good to me= . I reviewed and approved the PR right now.

 

Cheers,

Med

 

De : Marco Tiloca <marco.til= oca=3D40ri.se@dmarc.ietf.org>
Envoy=E9 : vendredi 12 d=E9cembre 2025 19:27
=C0 : The IESG <iesg@ietf.org>; BOUCADAIR Mohamed INNOV/N= ET <mohamed.boucadair@orange.com>
Cc : draft-ietf-core-oscore-groupcomm@ietf.org; core-chairs@iet= f.org; core@ietf.org; christian@amsuess.com
Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-core= -oscore-groupcomm-27: (with COMMENT)

 

 

Hello Mohamed,

 =

Thanks a lot for your re= view! Please find in line below our detailed replies to your comments.=

 =

A GitHub PR where we hav= e addressed your comments is available at [PR].

 =

Unless any concern is ra= ised, we plan to soon merge this PR (and the other ones related to other re= ceived reviews) and to submit the result as version -28 of the document.

 =

Thanks,

/Marco=

 =

 =

From: M= ohamed Boucadair via Datatracker <no= reply@ietf.org>
Sent: Tuesday, October 7, 2025 4:04 PM
To: The IESG <iesg@ietf.org= >
Cc: draft-ietf-core-oscore-groupcomm@ietf.org <draft-ietf-core-oscore-groupcomm@ietf= .org>; core-chairs@ietf.org <core-chairs@ietf.org>; core@ietf.org <core@ietf.org>; christian@amsuess.com <christian@amsuess.com>; christian@amsuess.com <christian@amsuess.com>
Subject: Mohamed Boucadair's No Objection on draft-ietf-core-os= core-groupcomm-27: (with COMMENT)

 

Mohamed Boucadair h= as entered the following ballot position for
draft-ietf-core-oscore-groupcomm-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://eur05.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&a= mp;data=3D05%7C02%7Cmarco.tiloca%40ri.se%7Ccb9508054ed14fcef77a08de05aa6879= %7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638954426619398033%7CUnknown%= 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI= kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D1FkxhoZAcpXWT2ttIs= AnJ6I7bRab3NTIhGUKMzJb8CE%3D&reserved=3D0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur05.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdr= aft-ietf-core-oscore-groupcomm%2F&data=3D05%7C02%7Cmarco.tiloca%40ri.se= %7Ccb9508054ed14fcef77a08de05aa6879%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%= 7C0%7C638954426619423444%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl= YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7= C%7C&sdata=3DuTm9wYR3yd20VE%2FUUbtXjoIbIl2ZdZiyGaLRbpb0o8s%3D&reser= ved=3D0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Marco, G=F6ran, Francesca, John, and Rikard,

Thanks for the effort put into this spec. I appreciate the discussion in
Section 12, in particular.

Please find below some comments:

# Re-keying & Observe

CURRENT:
   *  Long exchange: an exchange of messages associated with= a request
      that is a group request and/or an Observe re= quest [RFC7641].

I wonder whether there any impact of key change on installed observed.=

 

=3D=3D&= gt;MT

&n= bsp;

By desi= gn, there is no impact, except for a very specific case that is detailed be= low.

&n= bsp;

As to t= he general case, Section 3.4 "Additional Authenticated Data" expl= ains that the new element 'request_kid_context' in the aad_array achieves p= recisely the seamless and safe preservation of active long exchanges (including observations), also after a group rekeyin= g has occurred.

&n= bsp;

&n= bsp;

As to t= he particular case, a group member might be evicted from the group precisel= y to prevent by construction that any long exchanges can remain active unsa= fely.

&n= bsp;

This co= ncerns a particular, delicate situation that can arise during the lifetime = of a group and throughout instances of group rekeying, if the Group Manager= is configured to reassign Gid values as defined in Section 12.2.1.1.1.

&n= bsp;

In such= a case, in the interest of safely preserving long exchanges, the Group Man= ager has to additionally store the "Birth Gid" of each group memb= er, i.e., the Gid that was provided to that member at its latest group (re-)joining.

&n= bsp;

When re= keying the group and thereby establishing a new Gid value, the Group Manage= r must determine whether there are "elder" group members whose as= sociated "Birth Gid" is equal to the new Gid to establish. If that is the case, then the group rekeying has to effectively= evict from the group also such group members.

&n= bsp;

Consequ= ently, as stated at the end of Section 12.2.1.1.1:

&n= bsp;

* Exclu= ded elder members could eventually re-join the group, thus terminating any = of their ongoing long exchanges (including observations).=

&n= bsp;

* It is= ensured by construction that there cannot be long exchanges that are activ= e unsafely. That is, it is ensured that no client can have with the same se= rver two ongoing long exchanges, such that the two respective requests were protected using the same Partial IV,= Gid, and Sender ID.

&n= bsp;

<=3D= =3D



# To whom?

CURRENT:
   How the Security Context is established by the group members i= s out
   of scope for this document, but if there is more than one Secu= rity
   Context applicable to a message, then the endpoints MUST be ab= le to
            &nb= sp;            =             &nb= sp;            =           ^^^^^^^^^^
   tell which Security Context was latest established.
   ^^^^^^

=3D=3D>MT

&n= bsp;

We have= rephrased as below, to have the intended meaning explicit.

&n= bsp;

OLD

> ..= . then the endpoints MUST be able to tell which Security Context was latest= established.

&n= bsp;

NEW (em= phasis mine)

> ..= . then the endpoints MUST be able to **determine** which Security Context w= as latest established.

&n= bsp;

<=3D= =3D


# Capability

CURRENT:
   An endpoint of the group may use the group mode (see Section 7= ), the
   pairwise mode (see Section 8), or both, depending on the modes= it
   supports and on the parameters of the Security Context.

Is there a need to know in advance with a remote endpoint supports one or a= ll
these modes? Does that have impact on how contexts are established?

 

=3D=3D&= gt;MT

&n= bsp;

The sho= rt, practical answer is "no" to both questions.=

&n= bsp;

There i= s intentionally a separation between, on one hand, what modes are "ena= bled to be used" in the group according to the decision of the Group M= anager, and, on the other hand, what modes an individual group member supports.

&n= bsp;

The est= ablishment of the Security Context is largely based on the information and = parameters obtained from the Group Manager. That's sufficient to indicate w= hether one mode, or the other mode, or both are "enabled to be used" in the group. Consequently:

&n= bsp;

* A gro= up member supporting a mode will be effectively able to use that mode, if t= hat mode is enabled to be used in the group.

&n= bsp;

* A gro= up member (irrespective of what it supports) knows about the mode(s) that a= re enabled to be used in the group, while it does not know what another gro= up member supports until communicating with that other group member.

&n= bsp;

If the = use of the pairwise mode is not enabled in the group and/or a group member = does not support the pairwise mode, then that group member does not install= :

&n= bsp;

* Pairw= ise Sender Keys for the other endpoints, in its own Sender Context.

&n= bsp;

* The P= airwise Recipient Key for any other endpoint, in its own Recipient Context = corresponding to that other endpoint.

&n= bsp;

The abo= ve is highlighted in Figure 1 of Section 2. Similarly, other parameters in = the Common Context are not relevant to install if they pertain to a mode th= at is not enabled to be used in the group and/or that the endpoint does not support.

&n= bsp;

<=3D= =3D



# How the limit is know? Can that be retrieved from the system and exposed = to
the app?

CURRENT:
   An endpoint may admit a maximum number of Recipient Contexts f= or a
   same Security Context, e.g., due to memory limitations.  = After
   reaching that limit, the endpoint has to delete a current Reci= pient
   Context to install a new one (see Section 2.6.1.2).  It i= s up to the
   application to define policies for Recipient Contexts to delet= e.

 

=3D=3D&= gt;MT

&n= bsp;

It's no= t that the maximum number can be "retrieved from the system and expose= d to the app".

&n= bsp;

Like st= ated later in Section 2.6.1.2, "Group OSCORE in itself does not establ= ish a maximum number of Recipient Contexts".

&n= bsp;

In fact= , the application is also meant to define that maximum number, together wit= h the policies about deleting Recipient Contexts.

&n= bsp;

We have= rephrased and improved the last sentence as below:

&n= bsp;

OLD

> It= is up to the application to define policies for Recipient Contexts to dele= te.

&n= bsp;

NEW (em= phasis mine)

It is u= p to the application to define **the maximum number of Recipient Contexts f= or a same Security Context as well as policies for deleting** Recipient Con= texts.

&n= bsp;

<=3D= =3D



# Tracking/Logging

CURRENT:
   The Security Context may contain a large and variable number o= f
   Recipient Contexts.  While Group OSCORE in itself does no= t establish
   a maximum number of Recipient Contexts, there are circumstance= s by
   which implementations might choose to discard Recipient Contex= ts or
   have to do so in accordance with enforced application policies= .  Such
   circumstances include the need to reclaim memory or other reso= urces
   on the node hosting the endpoint, for example because the pred= efined
   maximum number of Recipient Contexts has been reached in the S= ecurity
   Context (see Section 2.2).

How these discarded contexts are tracked? Are there some king of
alarm/notification to warn this?

 

=3D=3D&= gt;MT

&n= bsp;

They ar= e not tracked and Group OSCORE in itself does not need to specifically trac= k/log their deletion.

&n= bsp;

Group O= SCORE in itself only needs to switch into initializing the Replay Window of= new Recipient Contexts as invalid, if those are created after the first de= liberate deletion of a Recipient Context (see third paragraph in Section 2.6.1.2).

&n= bsp;

If an e= ndpoint N_1 deletes a Recipient Context associated with another endpoint N_= 2, then N1 will be later able to create a new Recipient Context associated = with N_2, when receiving a message from N_2 (just like it did the first time).

&n= bsp;

Since t= he application might have some interest in logging these deletions, we have= extended the text as follows.

&n= bsp;

NEW (em= phasis mine)

> Su= ch circumstances include ..., for example because the predefined maximum nu= mber of Recipient Contexts has been reached in the Security Context (see Se= ction 2.2). **Implementations can provide means for the application to gain knowledge about the deliberate deletion = of Recipient Contexts, e.g., through notifications sent to the application = and/or logs made available to the application.**

&n= bsp;

<=3D= =3D



# Is there a reason what the Group Manager may not be informed? ShouldnR= 17;t such
event be logged locally, btw? Shouldn’t the manager be contacted prio= r to
exhaustion and not wait for full exhaustion?

CURRENT:
   Upon exhausting the Sender Sequence Number space, the endpoint= MUST
   NOT use this Security Context to protect further messages incl= uding a
   Partial IV.

   When approaching the exhaustion of the Sender Sequence Number = space,
   the endpoint SHOULD inform the Group Manager, retrieve new Sec= urity
   Context parameters from the Group Manager (see Section 2.6.3),= and
   use them to derive a new Sender Context (see Section 2.2).

 

=3D=3D&= gt;MT

&n= bsp;

Address= ing the three questions in order:

&n= bsp;

**1.** = Is there a reason what the Group Manager may not be informed?

&n= bsp;

There i= s no particular reason to inform the Group Manager specifically about that.=

&n= bsp;

In prin= ciple, the endpoint in question can also live with the situation safe and w= ell, as long as it is not going to consume new values of its Sender Sequenc= e Number. This is the case, e.g., if the endpoint plans to not send any message at all for a long while, or onl= y to send first-responses to a given request (which do not need to consume = a Sender Sequence Number).

&n= bsp;

In orde= r to start over with new keying material and Sender Sequence Number 0, inde= ed an interaction with the Group Manager is required. That interaction is s= pecifically a request to re-join the group or for only obtaining a new Sender ID, and it abstracts away from th= e particular underlying reason.

&n= bsp;

**2.** = Shouldn't such event be logged locally, btw?

&n= bsp;

We don'= t see any particular reason or advantage in doing that.

&n= bsp;

**3.** = Shouldn't the manager be contacted prior to exhaustion and not wait for ful= l exhaustion?

&n= bsp;

Indeed.= This is what the fourth paragraph in the same Section 2.6.2 already says a= fter the quoted text above, i.e.:

&n= bsp;

> It= is RECOMMENDED that the endpoint takes this course of action with some mar= gin, i.e., well before exhausting the Sender Sequence Number space, in orde= r to avoid a period of inability to protect messages including a Partial IV.

&n= bsp;

<=3D= =3D



# Not new behavior: cite as quote

OLD:
   As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests = sent
   over multicast MUST be Non-confirmable, and thus are not
   retransmitted by the CoAP messaging layer.

NEW:
   As per [RFC7252][I-D.ietf-core-groupcomm-bis], “group re= quests sent
   over multicast MUST be Non-confirmable”, and thus are no= t
   retransmitted by the CoAP messaging layer.

And

OLD:
   According to Section 5.2.3 of [RFC7252], responses to Non-conf= irmable
   group requests SHOULD also be Non-confirmable,

NEW:
   According to Section 5.2.3 of [RFC7252], “responses to N= on-confirmable
   group requests SHOULD also be Non-confirmable”,

 

=3D=3D&= gt;MT

&n= bsp;

Let's t= ake the two suggestions separately.

&n= bsp;

&n= bsp;

**On th= e first suggestion**, there is no single, common sentence that we can quote= verbatim from those two documents. The closest sentences that they have ar= e:

&n= bsp;

In RFC = 7252

&n= bsp;

* Secti= on 8.1, "Such multicast requests MUST be Non-confirmable."

&n= bsp;

In draf= t-ietf-core-groupcomm-bis

&n= bsp;

* Secti= on 3.1.1, "All CoAP requests that are sent via IP multicast MUST be No= n-confirmable (NON)".

&n= bsp;

* Secti= on 3.6, "An IP multicast request MUST be Non-confirmable (Section 8.1 = of [RFC7252])."

&n= bsp;

Instead= , we have rephrased as below to simply state a fact, without restating thro= ugh normative language, i.e.:

&n= bsp;

NEW (em= phasis mine)

> As= per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent over multi= cast **are always** Non-confirmable, and thus are not retransmitted by the = CoAP messaging layer.

&n= bsp;

&n= bsp;

**On th= e second suggestion**, that works but we have to use (part of) the sentence= from RFC 7252 verbatim, i.e.:

&n= bsp;

> If= the request message is Non-confirmable, then the response SHOULD be return= ed in a Non-confirmable message as well. However, an endpoint MUST be prepa= red to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) in reply to a C= onfirmable request, or a Confirmable response in reply to a Non-confirmable= request.

&n= bsp;

So we h= ave extended our text as below.

&n= bsp;

OLD

> Ac= cording to Section 5.2.3 of [RFC7252], responses to Non-confirmable group r= equests SHOULD also be Non-confirmable, but endpoints MUST be prepared to r= eceive Confirmable responses in reply to a Non-confirmable group request.

&n= bsp;

NEW (em= phasis mine)

> Ac= cording to Section 5.2.3 of [RFC7252], **"[i]f the request message is = Non-confirmable, then the response SHOULD be returned in a Non-confirmable = message as well. However, an endpoint MUST be prepared to receive (...) a Confirmable response in reply to a Non-confirm= able request."**

&n= bsp;

<=3D= =3D



Cheers,
Med


____________________________________________________________=
________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_PAUP264MB67561968BF7F97043352437388A9APAUP264MB6756FRAP_--