Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

David Navarro <david.navarro@ioterop.com> Tue, 08 November 2022 15:35 UTC

Return-Path: <david.navarro@ioterop.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BEDC14E514 for <lake@ietfa.amsl.com>; Tue, 8 Nov 2022 07:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.796
X-Spam-Level:
X-Spam-Status: No, score=-6.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ioteropcom.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WobzOw-0qBpb for <lake@ietfa.amsl.com>; Tue, 8 Nov 2022 07:35:34 -0800 (PST)
Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90124.outbound.protection.outlook.com [40.107.9.124]) (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 A4F9DC14F612 for <lake@ietf.org>; Tue, 8 Nov 2022 07:35:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PPAKE6yTa2Liy9khWs5gfsuQGs78AOa/9FZxzh7A6y/zSJQwgXvDt28f2emrwmB28RAoPyNF5QODWxDGA4wi3xGZLq76F8Elkl07W5WBNzRDeshmgU1mpBJIn6XWlrR6brgCZoqlQf/x3Wvis3z34GG6N4vjmHl9IGNQuzuamWmHmmyKBDisY3tQqeTuru3jVIGXSCEgtsFJTKGCq4wj8bNXY16ZpOj4SnGt0Rey3yOoyDDlGfg/bdewaDtW3RQEoNFh0uh8MxNjXKWDmo5DzfgVPI2E2BE/bjJNtmTbT5uzU8erO2HRsvuQewoil5Y2rC36QVlK+HXPuaUvWBiAnw==
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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=omHAnBo3/7zvu5mSlj65r6oHumLA1x1V7QMyr2RI1nM=; b=Qnmw1XeLvRT287nAyPp7KJVSrQ5Mgf9Icwk8wxa4FVT++f0gkbuMqKk/EG4Kttq1a6YIJmI2nPDqNFUJ5kh0ANBR7ZRNpdc/JOiazk2tTHLnWCqVvYo6temo4Oie/9XApwT1tJABBmBvcd9aIylWhyR1zfKYBlLUILC1bmZ3981nyUR268n6V7/0fHqw3cOjpMN7zlW6wMzTYcAVGadCIJV/1IiR8x8ZtjUpC8jnHeCP41LoRolhQa9VtgXpLGh387oWmMTG58S0/skwWpp5xtvTeuxf9DbY4DHuvy2B48rn6yNzM92fjkmhyK+J1QOzp1QT3qXGsivExAdFQtxngA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ioterop.com; dmarc=pass action=none header.from=ioterop.com; dkim=pass header.d=ioterop.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ioteropcom.onmicrosoft.com; s=selector1-ioteropcom-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=omHAnBo3/7zvu5mSlj65r6oHumLA1x1V7QMyr2RI1nM=; b=hs7Aa2AutjU1oD6hgUK4pfD4hlAJrjlXbXnGtwaqHQzEmJySRenvYuAQ3yWpzepsFT3OPsAZYiMC13FZKGJHux6OzM0+HBbwAvRMS3yYRWXTF4rY3NAD5Z09QDiRynnh+xHOdRkBn8wMg52AeQfuy3OxAs6rJSdEDjIOE5Bo8yQYRkl0k1YkuC/bhpX+Gain9xhOH8dXbvFnCv1x941dTJhywOJssIYDmMYpdMMkf62Y/yD0tmm+QdpK06y0KNUGlwTiuzteQ7c9dXKqeWd8K70uL3FLIYTVAARgHaft6m6hpGmEBaY4rW+46M6qeQ48OVP4FhfMv17unwro++hOMw==
Received: from PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:142::6) by PR0P264MB3030.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1d5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.27; Tue, 8 Nov 2022 15:35:26 +0000
Received: from PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM ([fe80::1fa6:bca2:c4ee:1302]) by PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM ([fe80::1fa6:bca2:c4ee:1302%4]) with mapi id 15.20.5791.025; Tue, 8 Nov 2022 15:35:25 +0000
From: David Navarro <david.navarro@ioterop.com>
To: "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Thread-Index: AQHY74yl9EytX4/EvUaEUSDr6Xt4jK4uiBcAgAT7fgCAAaODMA==
Date: Tue, 08 Nov 2022 15:35:25 +0000
Message-ID: <PR1P264MB349671BF1EFCD9F9F0B21594E83F9@PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM>
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr> <4d31934f-2a26-3392-8511-934e0dbeeb35@inria.fr> <HE1PR0701MB3050E43114D34FCF351A31E0893B9@HE1PR0701MB3050.eurprd07.prod.outlook.com> <HE1PR0701MB3050D59D877EEFF607460963893C9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB3050D59D877EEFF607460963893C9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ioterop.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PR1P264MB3496:EE_|PR0P264MB3030:EE_
x-ms-office365-filtering-correlation-id: b1328d6a-cfda-4834-3d8c-08dac19edb93
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pzO/I5fk/zkmtHhxqryKyY9cLFUaQQ3ygbHDNIiWR1mchWUAhqwE0N1FjiSgKJTX3TObOL6yn4i+V/CK2dpD0v0+zGtW9IRtet6TLTv3LWtgWMhNZVopBrOGsuCHt6HTvZk6PKfJNOjPk6WL5xSWdSB6AEvLiduM0lGYxMYybENAuNSKG5NrEu89SfnhZq9SLz9eET5s6w5Z/RvuGZ0Jr92yLd6dy4Xo4+Mjfu3wZ/cin5dw/PWrrdlwc5EUHzVDzc/uXb7z85m+GPdEnT6eVJkUj6FdAh7CRoBrrb5Q3+VkP4YaqlfIx4oIJKleZZ/GXT5SBB5eQuIWyiDp8JBjV3fyHcarx/lkNuDi/Zb1CVhJ65vldbOsaFyRNZ0ePWDiHSQZfMwJK8IBQavQTC1myAm7nLNsbmtoxNWWcdhfjWP4mpgiquK6ELgAjKWCd4Hbg4wpuWuqYzO9d0a/KM4P0pWWSdECqzTr9Cnzinpb3dsyric5gQL7N57U6ps/x4vDXL/AaVAbAgc6FN7Z6SEUONzPm7RjRNKR6H4DHRGuQWxZBxVYevNu9ui76zqZpwClvAYSvgp9HqqwTud1pJ6kcGrEyh6BZPgmEbPe9zJE8siBl1KyaC6LkHY3LSLZoNbajh6c2r753ewOkPiip1qP7qvpYmI/a37oV7uTIyqElCUl/YA77aYyS0UruhvCdDqppZesc00zJNTs18/oh/VFydOtjB38UiOOYaQG7Zyuvf2yMdjJjHgGeFGfNKdQl8Z88t0GmJI3UGlwL/YNcwbmp5bl9Rb0mzM5VRW7oGvswz4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(366004)(346002)(376002)(136003)(39840400004)(396003)(451199015)(1690799008)(6916009)(66946007)(76116006)(71200400001)(33656002)(66556008)(38070700005)(64756008)(66446008)(66476007)(316002)(86362001)(8936002)(66574015)(5660300002)(7696005)(6506007)(9326002)(41300700001)(52536014)(9686003)(53546011)(122000001)(966005)(55016003)(2906002)(478600001)(83380400001)(44832011)(186003)(38100700002)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: uLjPavFpIm4cs+yVlsetxFjUsRv6CGJYCh/2JDhYn2V+hj43szEjHNztgwq5a6tJMc+qOhkZBDphCuBmEpZaHbSThJ5nIwe0TtnOVPVdnEB1rSlp68woEc17YtuZwTkJN9M8qW4FgirQZhueiBQByFmN6Wnk7f8Uh5waJMU9f1Oi1mNTlze+Sxv+VP1SWdMtVME58VdFTBdutIXTnGeMG8qULVDTZguG51VqJqPgmQk3wQvS2f0rZv8LMcRH+p1sBON3jNvQHZWEidQOV3ExVjX0g8k72DSWeNhAe/RE8zZOBsGvLmdTpg4vX4a3fRku6g37vnWb49arjMIIhQbfzzqC7klZtDrAOMP6xnCR3hU+HOhTCqmSLYQwF3e5Lw2nu8SWAAvWipcmkETjgO+AX4ws9bLH/1gH7JuQScDhEK0b7WbLFtli5ObIIptpCS2IFknwIApvwCpNiQizL/6QjBH0ESBXCI8+Uq6FUuXXjvmdQ2OL/EEYSdNp3MB5YqvPY6LE9GtcmcLpfXa7L4USyEybzEzxPChwG6zwJ0iV1JohdeAg774BKU0JrVg1gaA7yT4H5/6bpVg35obs5YqcTUFJgPo5pPYAO46yj9tM6nKzxV29IBqupwLeIwQ8sdsK0AddZ75quSCJ9Db/3Aznj/lqv5VxHdrhQgwI5McUdN3CVDAmnjuVJzCWlcJM+zrg9rLnnBmtY1lrfEbPY9mwwEmU8ZgDNQ4h49fOtvfp5jj4c9KiPapfMurYdYnI4MN7T7E6BjEVMfRN+X+VjBQXUerSGwhyKEwECsB7Ra6LwStGaG71mWaocacBfAemXIl8NRNTXPIxgRPfFHe1jhRgK7+zmeOD1XSUh5eLUZXCdEY4Vm4YccjzJUggjMqduyawuZ1g4jexzok41YzQKyEbqz9X148jbbpDsH8pqqc1bobXLWWfhDP65a0Kf3cF/2M1gbEIyv0olPA47jW/sfs2G92wmolJePpILaXtVQx3ccx9MM7YvX3GS/ixB7xlj9xck5t8jl/1KNK/XNnfg36K1VqSLMv6O/B0Sxd4nW0LJTQfdOJdQQZlRnFM6qnNRAB/Thqhpx1PrsY4Z5wx37c+KvsT58KrwHq+s1G47gazjNfuJdvygC9UtyNfUIheUvtD4dpPVb8o8erldVZOeiPA6G493q6L08u+5D+ighfqNi9nVQvXuWnQINGrHXRG10siFbug2jC9tgNIkk/Vmco7a6FpZCCUvcXuwx2DONXHAdzbpiNW8oMnsREReXaLEP5jfDUi2gRmh3k06y9oQTUpcuRUDWxubqo1AEr3SGWVnIijfhCq/Tst7fmVgSZXLAaWxRRG2o3J8VyWkLfC0j5svYb3Ii76b4OwQ6SBb4dzvKy1oGbf5wk1a84wXvBZ7SUiFImWTRzhegy+gvd9j3iwHTg7NnEisP9XS1C6NZIQ/r1xHX4IFv192S5/QfKaA9kNdM84qfSXpBAuzm/l9IqEsFElKRlkj5m8P66X3mK7ewEg6Ea12Ndidr5GsE17xx3r8Lej3AZE/oMckGl7M79MvXT4oD8KsGOstD2sZorLvgjG+6kD0ZmtvpDAYiBBb2NVehcL6ZEyuUsdyXubQJu9H+ye4cszM3u+Q7ZKWvyrlOBme/0jMSdKfL9JCr1x7QAg
Content-Type: multipart/alternative; boundary="_000_PR1P264MB349671BF1EFCD9F9F0B21594E83F9PR1P264MB3496FRAP_"
MIME-Version: 1.0
X-OriginatorOrg: ioterop.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR1P264MB3496.FRAP264.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: b1328d6a-cfda-4834-3d8c-08dac19edb93
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2022 15:35:25.9043 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c0df38cb-a6d1-4728-a099-b8bb2ed471dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RDn7PjxETx9l0A8rUOb3RKIdmntKXAB8FHj9o7SR6Ue0nFtSeZfG8pjhTJGSivB//pW7WhAsTKD1ERh6cpj7ipCRU1T1NjNITvKbqFp46KE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR0P264MB3030
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/mHtKX_viOSvPkdlpB_7Kp5dN8Wk>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 15:35:38 -0000

Hi,

Sorry for my late comment.

Some background:
SEC 1: Elliptic Curve Cryptography (https://www.secg.org/sec1-v2.pdf) defines two representations for Elliptic Curve Point of Weierstrass curve families public keys (section 2.3.3):
  - the uncompressed representation: byte 0x04 followed by the X coordinate and the Y coordinate.
  - the compressed representation: byte 0x02 or 0x03 followed by the X coordinate. The value of the first byte depends on the sign of the Y coordinate.

The latter format is not used in TLS for Intellectual Property reasons. The COSE RFC contains the following statement:
"Generally, protocols transmit elliptic-curve points as either the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding has not been recommended by the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y-coordinate is potentially useful."

draft-ietf-lake-edhoc-17 in Appendix B specifies a compact representation for Elliptic-Curve-Point which is (probably) subject to the same IPR considerations.
Maybe this could be indicated in the text.

Another possibility would be to mandate the usage of the SECG encoding in G_Y and G_X. While this would add an unnecessary byte, it would allow implementation to avoid the IP contamination by using the uncompressed representation.

Regards,
David Navarro

From: Lake <lake-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Monday, 7 November, 2022 14:01
To: Charlie Jacomme <charlie.jacomme@inria.fr>; lake@ietf.org
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

Charlie Jacomme wrote:
>and would only be caught on a message 4 or key confirmation.
Just like changes to PAD_2 I think it the changes would be detected when verifying CIPHERTEXT_3

John wrote:
>I assume that someone also theoretically could register a randomized AEAD in
>COSE which would only be EUF-CMA.
My bad, such an AEAD would not pass the IND-CCA game I think.

From: John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>>
Date: Friday, 4 November 2022 at 09:55
To: Charlie Jacomme <charlie.jacomme@inria.fr<mailto:charlie.jacomme@inria.fr>>, lake@ietf.org<mailto:lake@ietf.org> <lake@ietf.org<mailto:lake@ietf.org>>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Hi Charlie,

Good catch, I think we should do some small update so the text is correct. My understanding is that EdDSA (The IETF standard) is SUF-CMA, while ECDSA, RSASSA-PKCS1-v1_5, and RSASSA-PSS are EUF-CMA. I do not know about HSS-LMS.

I assume that someone also theoretically could register a randomized AEAD in COSE which would only be EUF-CMA.

Cheers,
John

From: Lake <lake-bounces@ietf.org<mailto:lake-bounces@ietf.org>> on behalf of Charlie Jacomme <charlie.jacomme@inria.fr<mailto:charlie.jacomme@inria.fr>>
Date: Thursday, 3 November 2022 at 15:01
To: lake@ietf.org<mailto:lake@ietf.org> <lake@ietf.org<mailto:lake@ietf.org>>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
Hi all,

Following our previous analysis of the draft 12 and 14, we have now updated our models w.r.t. draft 17, making a full pass over both the protocol changes as well as the security considerations mentioned through out the draft.

Overall, there is a last security claim that is slightly wrong from a theoretical point of view, but in practice does not bear consequences. We detail it bellow. Otherwise, our automated analysis was not able to find any other weakness, so we hope that with respect to state of the art analysis techniques, the protocol is in a pretty good shape.

It concerns the following point, page 42:
    "Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2. "

This claim in fact depends on the security level of the signature scheme used. Assume that we have a signature scheme such that given "Sign(m,sk)", the signature of message m with secret key sk,  there exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid signature for the same message m under sk. This is not a violation of the classical assumption over signatures (EUFCMA), and with such a signature scheme, an attacker could then change the content of message_2, by xoring the signature part with the constant c, and this change would not be detected after verifying the signature, and would only be caught on a message 4 or key confirmation.

This is only a theoretical attack, relying on the difference between the classical cryptographic assumption EUF-CMA, a signature authenticates only the underlying message, while under the stronger SUF-CMA assumption, a signature authenticates both the underlying message and the signature itself.  None of the concrete signature scheme currently standardized appears to be malleable under xor. We report it for thoroughness, but are uncertain whether the sentence should be changed or not.

Best,
Charlie Jacomme, Elise Klein, Steve Kremer and Maïwenn Racouchot.
On 14/10/2022 12:24, Mališa Vučinić wrote:
Hi all,

As discussed during the interim on 5 October 2022, this email triggers the working group last call for the version 17 of the EDHOC draft, the main item on the agenda of the LAKE working group.

The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/

Please state your position and comments to the list by 4 November 2022 so we can discuss them during the IETF 115 meeting in London.

Thanks,
Mališa, for the chairs





[ioterop-your-lwm2m-partner]<https://ioterop.com/>

[social-icon-linkedin]<https://www.linkedin.com/company/7955832/> [social-icon-twitter] <https://twitter.com/ioteropcompany>  [social-icon-facebook] <https://www.facebook.com/IoteropCompany/>