Re: [Lake] Lars Eggert's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)

Göran Selander <goran.selander@ericsson.com> Wed, 23 August 2023 11:59 UTC

Return-Path: <goran.selander@ericsson.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 BD6BDC1519B3; Wed, 23 Aug 2023 04:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stmaBsve6LIW; Wed, 23 Aug 2023 04:58:55 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2055.outbound.protection.outlook.com [40.107.20.55]) (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 8C3F3C151084; Wed, 23 Aug 2023 04:58:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HPcu7mm6rqr9bPIFDHlTLrcou9V1+lqbxoBJB4XCGA0PWVjuqJpjJnhBSKvUX4qdhjJd5lyOfTTQmTBEZ/PDOiMRVvDO2DJhXCOWJFs8j3MueAV/0QHsRLHoAxQ3zyKMcpGAowCA6yw68aQ26i5tGTHkWHvFPTGa86yRKcAlKKG4cdf3JOMw9UsftEIHme9FV7NI/cjqniW1z7ekLmAEtBNKJZzsqBmxFoSZ9BawFDzwFmAFsryyZXNPmTRBVC8RvQ06BXgy8YF7UrtfXwDc43w2IHKHrl6Oq315RkJ8y8QAvDq/xEwLj8wOoiAaLmLOfRkQPsRgJSyi2rKjpamzig==
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=MozfvodnSOCcjxAiTy3HpsWrpWL/j2tGeDadsBcvjRE=; b=DlHZOj284v9p/YznO8NEdR1TuxB9huUv+eYE4PMMRhXOOciveGezESDTBWXPWHhPcccj3SdBK9ldawTcybDhYtPV1uNWlJWMnBEtkkkFHCmPGTUxyMddadzdQRcZ1CflZjIKugQjN3Wl61A/gKxq+8reuSVdZ1ilIq1r48ThltomitPCfHHg77C8zQkyp2a796soGKsFwOUfhluXfg8lxbnmUJe+XNCyQh1fzXnr5hX2g3ZZOMph/BU4FYU8nDgRkx6veSyFZVyLlAdZ0THKoCH7D/SOV7Y9NYg/73/z0gKnvrrfVNAfiVgBd+CiCH+ViVPvzcdtt/We58SyORzUmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MozfvodnSOCcjxAiTy3HpsWrpWL/j2tGeDadsBcvjRE=; b=CT2lrtdLHtaE8eFBaCO9P5DYvHqSnZeMnN7BlkGiuUfnjBMeKawcLABWDFb2HA8cKEqRrzzJl3BWpNJmJq7YXb0cZ/SgdWkrR32cVpHLAk0xkUohxFSD9FWSSit1SX7jE/T3neyMEkf7b35a72m/2A84FJVNYTCNCnb/xPaD2LA=
Received: from PAXPR07MB8844.eurprd07.prod.outlook.com (2603:10a6:102:24a::19) by PA4PR07MB7392.eurprd07.prod.outlook.com (2603:10a6:102:c1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.24; Wed, 23 Aug 2023 11:58:51 +0000
Received: from PAXPR07MB8844.eurprd07.prod.outlook.com ([fe80::471b:b4dd:2889:b028]) by PAXPR07MB8844.eurprd07.prod.outlook.com ([fe80::471b:b4dd:2889:b028%7]) with mapi id 15.20.6699.020; Wed, 23 Aug 2023 11:58:51 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-lake-edhoc@ietf.org" <draft-ietf-lake-edhoc@ietf.org>, "lake-chairs@ietf.org" <lake-chairs@ietf.org>, "lake@ietf.org" <lake@ietf.org>, "malisa.vucinic@inria.fr" <malisa.vucinic@inria.fr>
Thread-Topic: Lars Eggert's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)
Thread-Index: AQHZ1NIS6KDaESuMfU6fteHKGQkkqa/2Usxw
Date: Wed, 23 Aug 2023 11:58:51 +0000
Message-ID: <PAXPR07MB88445000744C02E8537C7C49F41FA@PAXPR07MB8844.eurprd07.prod.outlook.com>
References: <169269257169.1146.6134251465161445844@ietfa.amsl.com>
In-Reply-To: <169269257169.1146.6134251465161445844@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAXPR07MB8844:EE_|PA4PR07MB7392:EE_
x-ms-office365-filtering-correlation-id: e58377da-7982-40e8-862e-08dba3d05102
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: u1j5EdUmiqWQnT8T4MQQl6+W1Bu/Bzh4gycCMtevVCQx9okrwthh7ZIwc+xG4AYN4OoShKkmqTu/HmSJV/Hto7CABYaVN69Fboi5iJH5Dmm6ILMqmIUaOUfsuedik0rE6JeWcQiUXlqHLCyauo/O9mFQqJBtF9JN2b5qMXa2Y5Ptodh8kxQP1Y0qEVQjSg1KBbBQJ6JNN9h8fM1PyJuwkvzeiaEmlTLkqH9nY0EadD+tnrt3pGA3DY2B56cv91mN2O4T+OX0fvvTR78LLB9Ih51j+RdyPukoNB9AlWQ0TK8myqk5BFd1/E/WATJG8IGomDsYHiD0IEKJI3qc4w2hXfxXmmpdS8rb/oJiczcuEblI43wsN1THsZSljDzhXI5fPEjrVTLe4fBCQtq16fEr+hQEc/DxRkbbxCYFrrws/IoSjiMyUq9TxVYaCkjuh+BBsKfBeCf1WImvC1D0CyVUo46AwTgxN0MNKaSKI7QxDDR11ZcNRM0aeaPD+cROeWxfULAKLcVVEl/xZtug0/ASNoRQy1lYMSH86Rq8gV2babDQgUCfUt/3lYTw6Pn/ps6C3KxDtbizvQt5trr4JiVPEtgpTMQVsoPF9dp1CfqTld5Nc/JSL+Got3hgx2tevTOfd+z19+1ip4Lu2IOZyRNK1j9pqkKDU288ihH06ta1MYVOO5RpPBGxpJTqoWeK0YnaEOq3v0jKt+IR0S79dxr4AVfxswV8CCVCtEZoSVpqGUA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAXPR07MB8844.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(366004)(396003)(346002)(39860400002)(136003)(451199024)(186009)(1800799009)(478600001)(966005)(86362001)(41300700001)(9686003)(33656002)(12101799020)(110136005)(66946007)(76116006)(66476007)(66446008)(316002)(66556008)(64756008)(6506007)(7696005)(54906003)(53546011)(71200400001)(26005)(166002)(5660300002)(8936002)(52536014)(8676002)(4326008)(83380400001)(30864003)(2906002)(82960400001)(38100700002)(38070700005)(66574015)(122000001)(55016003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: os/YSck5XKkg+iAPR6YRieW5wEvfZAD7z+Zv0WRWZ7JWrx246LOoBzQwfgQ/Clh7tLlZEqsiJGAjo3x7fCOT8kxR3uOMkmSU9kcKVnpOqto9m0DVgPu0ktG1OJztSrgynEvkLU3p4LAYdqOzOt0T4FjAi3FN+yxS5ewmBKvPoNu27btPLdVXxxpqBuI9zKjSU75BQ+hh1vCKC2x0Cn5BRqMcuW60IMbn+kO4AXLgnD7jRwf7jmLk58yLYhJQ4IErTjb6tWDS8YafBqBcvNLzZR/ATB1/kebCGhdFjRdGdPUiEU7rt2wsxGmlDPIZG+TnXvuaItjKvczxOSlG71PdFcRTf02alZexqyMefTwxEQ82pW39EAfiqV/OA3JzPF5Ry4hLMAIQ36J2zFRNJNRV5Qij/gKP+V9BVTfIxciX3ssnDtzQkE4ONy3v1TFh2EPN3Vnklmz5Rn4gu6xhbp8YMDZkQcu3uwA4MR0aGJwA0il+UumPu6fOKKqW/8tSDcaoW6VVzO9WP1E/HbX35Y1BfPT5thFokkwKpc+NZa+Cx/vfkMiNUSZR2xUqvrO99Gzp86T8DYPwhz2vYbtKvLVI0MH58/T80zgoL38RgrS0sRMwErFYqHyjdjhVh0KLzKGdDMsM7VSYJ6Q0TUXloMU9d5yadK2I8JAlN8cygtJbkpkldIxcDrxMby0xyRgBAZi0KqH+wYlHGze2J0lWxaEGPw/mASjDQ6liigkHD0NW9C4L93A1LNsGQh7rnhHKj0AjTuDM4ynLnwt/EGilYVLp6g7CX1rmZyHxVdMvIPPrTYz3ni1WFXT+Q375wCrjt2FeI6E1x1wXS+/sNh9e9hLB+P6sr6066yXbcM1q/zl+KlxuHXG8s4MNc+yk7mCUIBYJb4bhVLyTMP+kSPepvgetVY1a+2QGueCPh1WgGjZA6cbLN/p9Q5iBapoS9mc06QmWGBBtiVRUkPn1GLzTiy8/jWzk2o26jyUdcoUatqbzFV7Z/Rxczti0U3yT1kkEuXn//dWChLdRC9sTqgM8AFBzAXi8HwAgfC1J5d/YFHo5jxOSq12zMM19fi76SNTCG7biwduHxXvzKMoh9wmvJL0Ir5iGgTrxIQMPXnKvYBtoYtw0WAix5Ufar2ilv58T2HltbMv0hIhyasuPIJf13mP4bfe6OqhihObEPP6xiAFT7YxGXRXa3NM9pxgSBhElpcb36vBV6UUsRs/piNSVMwEZwV1h2UmuoepiZ+39AWwGhH4RnVjBfVNIXd5oJ66PYyhRR+jCQNTH1gSc7EwtKK4tdwNilD0ySaVERlQ9yV3fGWZ0VX+vRfCTqCBtjp8X27+blm1mEy5tikHwjraB69enKfc0pke5ospIH4ALv1e08Ou0dCgOAM2RrL+tOYHmhxrjbnn/GQ2dX4OsvmgpAY6yd5ryAl9izckgG7GXqWlfNEZAAt0hxjjI73+MsmdTN+/pxzLojIT4ff9ass9/DOa0nXzgOKEdV6MzU2Eyi8rTU1EJh6k7hlMwH3tmOqvQfA5IaJsz1rBZ8soRJnB2S5qhtPvKPpBuAC5hUBaqz5HQ2QYshVO6wkekMSH1z3K+blSFYF2uBV+eBgDuqbYRafVNbyPD7FzNosy0zAZtwuKjHho=
Content-Type: multipart/alternative; boundary="_000_PAXPR07MB88445000744C02E8537C7C49F41FAPAXPR07MB8844eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAXPR07MB8844.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e58377da-7982-40e8-862e-08dba3d05102
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2023 11:58:51.0207 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XdMGN6VgvqamvDkWqwN8DTCtU6OoGXvqYar5lEvyP1vYB23tXPJBWKSt6H9ZfdsO7f49MIbrXTXeXRw8jSEg5zispH+8ZqEEB0f5HZPs5rc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB7392
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/ZNDy-K2lz-YY4utze6vwJMdPucg>
Subject: Re: [Lake] Lars Eggert's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)
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: Wed, 23 Aug 2023 11:59:00 -0000

Hi Lars,

Thanks for your review. I tracked it as github issue #417<https://github.com/lake-wg/edhoc/issues/417> and started PR #425<https://github.com/lake-wg/edhoc/pull/425>. Please see responses to your comments inline below.

 Göran

From: Lars Eggert via Datatracker <noreply@ietf.org>
Date: Tuesday, 22 August 2023 at 10:24
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lake-edhoc@ietf.org <draft-ietf-lake-edhoc@ietf.org>, lake-chairs@ietf.org <lake-chairs@ietf.org>, lake@ietf.org <lake@ietf.org>, malisa.vucinic@inria.fr <malisa.vucinic@inria.fr>, malisa.vucinic@inria.fr <malisa.vucinic@inria.fr>
Subject: Lars Eggert's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)
Lars Eggert has entered the following ballot position for
draft-ietf-lake-edhoc-20: Discuss

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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# GEN AD review of draft-ietf-lake-edhoc-20

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/tvJRHUSdUtXJpishMcOd0KwR4O0).

## Discuss

### Section 3.4, paragraph 6
```
     *  denial-of-service protection,
```
No IETF transport protocol provides DDoS protection. If this is an
actual requirement, how will it be provided?

[GS] Agree “protection” is not the right word here. DTLS uses “DoS prevention” for a similar property (Section 5 in RFC 9147) but “prevention” is perhaps even stronger than “protection”? We actually think “mitigation” is a good term to use here, which is synonym to “alleviation”/”diminution”/etc. I made a general replace to “mitigation” as placeholder pending an agreement on this point.

### Section 8, paragraph 3
```
     An implementation MAY support only a single method.  None of the
     methods are mandatory-to-implement.
```
How is interoperability guaranteed without at least a single
mandatory-to-implement method?

[GS] This has been discussed in the WG, in short it is the application profile (Section 3.9) which makes implementations interoperable. Considering the large variety of IoT applications and the potential constrainedness of target deployments it is not always feasible to implement other methods than those which are actually used. For example, for the most constrained devices it may only be possible to support method 3, whereas more traditional certificate based deployments would typically be based on signature public keys and method 0. The method is just one out of several parameters that needs to be specified in the application profile to achieve interoperability, including cipher suite, credential identification, etc.

### Section 9.7, paragraph 1
```
     state, perform cryptographic operations, and amplify messages.  To
     mitigate such attacks, an implementation SHOULD rely on lower layer
     mechanisms.  For instance, when EDHOC is transferred as an exchange
     of CoAP messages, the CoAP server can use the Echo option defined in
     [RFC9175] which forces the CoAP client to demonstrate reachability at
     its apparent network address.  To avoid an additional roundtrip the
     Initiator can reduce the amplification factor by padding message_1,
     i.e., using EAD_1, see Section 3.8.1.
```
While the Echo option prevents some resource exhaustion aspects of
spoofing, it does not prevent DDoS by actual CoAP clients. Likewise,
while limiting amplification reduces the impact of a DDoS attack by
actual clients, it does not prevent it. It is hence incorrect to say
that these attacks are mitigated by COAP. (They also wouldn't be
mitigated by any other IETF transport protocol.)

[GS] Good points, I added one paragraph to this section:
”Note that while the Echo option mitigates some resource exhaustion aspects of spoofing, it does not protect against a distributed denial-of-service attack made by real, potentially compromised, clients. Similarly, limiting amplification only reduces the impact, which still may be significant because of a large number of clients engaged in the attack.”
As above, I kept the term “mitigation” as in “to make (something) less severe, harmful, or painful” (Britannica) or “to cause to become less harsh or hostile” (Merriam-Webster). IMHO it seems to me to be an appropriate term to use. Happy to stand corrected.

### "A.2.", paragraph 1
```
     duplication.  CoAP can also perform fragmentation and protect against
     denial-of-service attacks.  The underlying CoAP transport should be
```
Per above, COAP does not protect against DDoS.
[GS] Replaced “protect against” with “mitigate certain”.

### "A.2.", paragraph 6
```
     To protect against denial-of-service attacks, the CoAP server MAY
     respond to the first POST request with a 4.01 (Unauthorized)
     containing an Echo option [RFC9175].  This forces the Initiator to
```
Per above, this mitigates some aspects of spoofing, but does not
protect against DDoS.
[GS] Replaced “protect against” with “mitigate certain”

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[GS] Resolved now.

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


## Comments

### Section 3.4, paragraph 5
```
     *  flow control,
```
But not congestion control?
[GS] CoAP, which is the default transport mechanism, provides flow control and congestion control, so those are indeed properties we expect from the transport. We added “congestion control” to the list. As discussed in the response to Martin Duke’s review, the security protocol strictly speaking does not require anything from transport but will not perform very well without suitable properties depending on the connection.


### Section 10.2, paragraph 17
```
     | -20 to 23      | Standards Action with Expert Review |
```
Why still Expert Review if this already requires a Standards Action?
(Same comment for other registry ranges with this policy.)

[GS] Ongoing thread on mailing list. With current last mail from Carsten no change will be made.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `master`; alternatives might be `active`, `central`, `initiator`,
   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
[GS] ”master” used in the terms OSCORE Master Secret/Salt which is the terminology used in RFC 8613.

 * Term `man`; alternatives might be `individual`, `people`, `person`
[GS] “man-in-the-middle” replaced with “active on-path”

 * Term `dummy`; alternatives might be `placeholder`, `sample`, `stand-in`,
   `substitute`
[GS] removed “dummy” as it was redundant

 * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`
[GS] “native” only used in the change log which will be removed before publication.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-2ff81d81b9b4007d&q=1&e=014883c7-9ca0-4d1a-a260-33fd1fa98485&u=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-selander-lake-authz-02`, but `-03` is the latest
available revision.

Document references `draft-ietf-core-oscore-key-update-04`, but `-05` is the
latest available revision.

Document references `draft-ietf-teep-architecture`, but that has been published
as `RFC9397`.

Document references `draft-ietf-cose-cbor-encoded-cert-05`, but `-06` is the
latest available revision.

Document references `draft-ietf-core-oscore-edhoc-07`, but `-08` is the latest
available revision.
[GS] Latest version will be fixed in the next version.

### URLs

These URLs in the document did not return content:

 * https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm
[GS] Changed to Wikipedia. Clarified the reference refer to CNSA 1.0.
https://en.wikipedia.org/wiki/Commercial_National_Security_Algorithm_Suite

 * https://webee.technion.ac.il/~hugo/sigma-pdf.pdf

[GS] Changed to IACR, short version of the paper, which covers the use in the document.
https://www.iacr.org/cryptodb/archive/2003/CRYPTO/1495/1495.pdf

These URLs in the document can probably be converted to HTTPS:

 * https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-e494bd73e348ae79&q=1&e=014883c7-9ca0-4d1a-a260-33fd1fa98485&u=http%3A%2F%2Fcbor.me%2F


[GS] Yes cbor.me now supports https

https://cbor.me/


### Grammar/style

#### Section 3.5.1, paragraph 2
```
n used by Initiator or Responder. Similarly for CRED_I, see Section 5.4.2. Th
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Similarly".

[GS] Comma doesn’t make sense here.


#### Section 4.1.1.3, paragraph 5
```
 used for two different purposes. However an application can re-derive the s
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

[GS] Done


#### Section 4.1.2, paragraph 1
```
al times as long as it is done in a secure way. For example, in most encrypt
                               ^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "securely" to avoid wordiness.
[GS] Done


#### Section 5.3.2, paragraph 17
```
s is similar to waiting for an acknowledgement (ACK) in a transport protocol.
                               ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.
[GS] Done


#### Section 6, paragraph 11
```
s 8 and 9, and prefers suite 8, so therefore selects suite 8 in the second m
                                ^^^^^^^^^^^^
```
Consider using "so" or "therefore".
[GS] Done


#### Section 6.3.1, paragraph 3
```
 multiple times due to missing acknowledgement on the CoAP messaging layer.
                               ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.
[GS] Done


#### Section 9.1, paragraph 6
```
e use of authenticated encryption. Hence the message authenticating function
                                   ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".
[GS] Done


#### Section 9.5, paragraph 1
```
rves such as Ed25519 and Ed448 can mapped to and from short-Weierstrass form
                                   ^^^^^^
```
The modal verb "can" requires the verb's base form.
[GS] Done


#### Section 9.8, paragraph 1
```
H_3, TH_4) does not make use of a so called running hash. This is a design c
                                  ^^^^^^^^^
```
The expression "so-called" is usually spelled with a hyphen.
[GS] Done


#### Section 11.2, paragraph 11
```
sage flow" (see Appendix A.2.2). By default we assume the forward message flo
                                 ^^^^^^^^^^
```
Did you mean: "By default,"?
[GS] Done


#### "A.1.", paragraph 4
```
t representation trivially avoids so called "benign malleability" attacks whe
                                  ^^^^^^^^^
```
The expression "so-called" is usually spelled with a hyphen.
[GS] Done


#### "A.1.", paragraph 6
```
yte 0x02 (i.e., M = 0x02 || X). * If a uncompressed y-coordinate is required,
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".
[GS] Done


#### "A.2.", paragraph 2
```
he major type. CBOR supports several different types of data items, in addit
                             ^^^^^^^^^^^^^^^^^
```
Consider using "several".
[GS] Done


#### "A.2.", paragraph 7
```
 CDDL C.2. CDDL Definitions This sections compiles the CDDL definitions for e
                                 ^^^^^^^^
```
Consider using the singular form after the singular determiner "This".
[GS] Done


#### "A.2.1.", paragraph 8
```
ing. What verifications are needed depend on the deployment, in particular th
                                   ^^^^^^
```
Did you mean "to depend"?
[GS] Replaced with “Which verifications that are needed depend on . . .“


#### "D.3.", paragraph 1
```
cation message is successful, then the the Initiator transitions from COMPLET
                                   ^^^^^^^
```
Possible typo: you repeated a word.

[GS] Done

#### "Appendix E.", paragraph 7
```
 with example state machine o Acknowledgements o Language improvements by na
                              ^^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.
[GS] Not done, change log will be removed.



## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-29a4b48826f5565a&q=1&e=014883c7-9ca0-4d1a-a260-33fd1fa98485&u=https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments%2Fblob%2Fmain%2Fformat.md
[ICT]: https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-0580e87653a1b8a9&q=1&e=014883c7-9ca0-4d1a-a260-33fd1fa98485&u=https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments
[IRT]: https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-2ff81d81b9b4007d&q=1&e=014883c7-9ca0-4d1a-a260-33fd1fa98485&u=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool