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

Amanda Baber <amanda.baber@iana.org> Wed, 23 August 2023 00:37 UTC

Return-Path: <amanda.baber@iana.org>
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 3B301C14CE40; Tue, 22 Aug 2023 17:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
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 NXe5wkEnYtSM; Tue, 22 Aug 2023 17:37:41 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 F26E7C151062; Tue, 22 Aug 2023 17:37:40 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa4.dc.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 37N0bTXx003000 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2023 00:37:29 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Tue, 22 Aug 2023 17:37:27 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.1118.030; Tue, 22 Aug 2023 17:37:27 -0700
From: Amanda Baber <amanda.baber@iana.org>
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: [Ext] Lars Eggert's Discuss on draft-ietf-lake-edhoc-20: (with DISCUSS and COMMENT)
Thread-Index: AQHZ1NHb4iHfAQnPAEm6gWDry/LPyq/3CkoA
Date: Wed, 23 Aug 2023 00:37:27 +0000
Message-ID: <D24E8455-02DB-4D54-8B37-62ADF79CAD2D@iana.org>
References: <169269257169.1146.6134251465161445844@ietfa.amsl.com>
In-Reply-To: <169269257169.1146.6134251465161445844@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.63.22070801
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3775570636_2361579691"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-08-22_22,2023-08-22_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/ZBfxGZQ5X8t5-_TKj0L05F3RdUQ>
Subject: Re: [Lake] [Ext] 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 00:37:45 -0000

Hi Lars,

We've received the expert approval we were waiting for, so your DISCUSS on behalf of IANA can be resolved. Thank you!

Amanda

On 8/22/23, 1:22 AM, "iesg on behalf of Lars Eggert via Datatracker" <iesg-bounces@ietf.org on behalf of noreply@ietf.org> wrote:

    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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkVjijLSU$ [ietf[.]org] 
    for more information about how to handle DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkdY13lQ0$ [datatracker[.]ietf[.]org]



    ----------------------------------------------------------------------
    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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/gen-art/tvJRHUSdUtXJpishMcOd0KwR4O0__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkHIFkT-c$ [mailarchive[.]ietf[.]org]).

    ## 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?

    ### 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?

    ### 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.)

    ### "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.

    ### "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.

    ### IANA

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


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


    ## Comments

    ### Section 3.4, paragraph 5
    ```
         *  flow control,
    ```
    But not congestion control?

    ### 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.)

    ### Inclusive language

    Found terminology that should be reviewed for inclusivity; see
    https://urldefense.com/v3/__https://www.rfc-editor.org/part2/*inclusive_language__;Iw!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkeWDqFo8$ [rfc-editor[.]org] for background and more
    guidance:

     * Term `master`; alternatives might be `active`, `central`, `initiator`,
       `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
     * Term `man`; alternatives might be `individual`, `people`, `person`
     * Term `dummy`; alternatives might be `placeholder`, `sample`, `stand-in`,
       `substitute`
     * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
       `intrinsic`, `original`

    ## 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://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkC0Yib-0$ [github[.]com]), 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.

    ### URLs

    These URLs in the document did not return content:

     * https://urldefense.com/v3/__https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkzMu4xXc$ [apps[.]nsa[.]gov]
     * https://urldefense.com/v3/__https://webee.technion.ac.il/*hugo/sigma-pdf.pdf__;fg!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkqNVbf2M$ [webee[.]technion[.]ac[.]il]

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

     * https://urldefense.com/v3/__http://cbor.me/__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkBZdddrw$ [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".

    #### 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".

    #### 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.

    #### 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.

    #### 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".

    #### 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.

    #### 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".

    #### 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.

    #### 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.

    #### 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,"?

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

    #### "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".

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

    #### "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".

    #### "A.2.1.", paragraph 8
    ```
    ing. What verifications are needed depend on the deployment, in particular th
                                       ^^^^^^
    ```
    Did you mean "to depend"?

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

    #### "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.

    ## 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://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkzSp_msA$ [github[.]com]
    [ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkvLwsAjE$ [github[.]com]
    [IRT]: https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!PtGJab4!7QGBb7qEyaB3rB2tVlzLIP6LaMbFp5F4Kw9AH_d75imQ9htcxsBpUHj16Wg8AzIVgFD70wFUXB0caArkC0Yib-0$ [github[.]com]