Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Göran Selander <goran.selander@ericsson.com> Wed, 04 March 2020 11:11 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 89DD03A0C82 for <lake@ietfa.amsl.com>; Wed, 4 Mar 2020 03:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZuUzelb7erK for <lake@ietfa.amsl.com>; Wed, 4 Mar 2020 03:11:27 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40049.outbound.protection.outlook.com [40.107.4.49]) (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 41F5A3A0C7F for <lake@ietf.org>; Wed, 4 Mar 2020 03:11:27 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3Dlin4yiGiamp7rptBDIiwgspNgvcHZzX/nJUiGU1MHq0kJj2aZPudyHCEMxoZY?= =?utf-8?q?VnH39j/jvftxfmPo+l4JwSJbOPz/XUNV0yTvc1f5whWYQ+CIr3ffQgTEsyNc0tfXn?= =?utf-8?q?fzIqVqj5vX0seNlyauhPEnZKHTq8CSZqIvsvFcNoA9vWo6UzPceKtLvyH1URj/G70?= =?utf-8?q?bRgkZFYW5TLPmu7W9Hq7Uib3Ni2EUcujITa4Dhu5xuOm2beWoU2AbPRUm3XkKK41Z?= =?utf-8?q?ivzNztZlOxnH8MHdEXks3yrJHNxrfxgllm7w6WHBsdIZVRITMi4ZXIF+4rxcgt3U9?= =?utf-8?q?mncs3CyYlktQYcaA+fN+Q=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3Dub8ZHjNxf4tQ/3JBAYNG1oU8gI7rqNgwrxMkWpDB9WU=3D=3B_b=3DIwcGJZ?= =?utf-8?q?WrTP424RNU1skLQ5v3z6k0W56WFOQF09VGdxIEhMbgz4Kt1mQcZy+j/RFTTvYsT6i?= =?utf-8?q?noUun5Cp+QcxTBEH9teInGHCB/g2Rf3EhPpOavRf7K0q8hefA4I4QAqJLceKo1t8A?= =?utf-8?q?RHjMMt2RTubRbYcBBHVBDOle+JHjJBf8NN4NFlHrFKhxSpbkQNo6F2uHAK13UE198?= =?utf-8?q?7C+J8EHsxDfxqyMrhyYtGcRogtdZ8bZEl+WMUUfJhozLYY79kL10rdIUL6Sria8pW?= =?utf-8?q?4+Xu1X4Wz1s1KUiFlNTFtaTk4OA3A++jh+t9fQPV4mXVeVJZ4VqWRpjQCL58esdhm?= =?utf-8?q?yGGkJBwqSUw=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3Dub8ZHjNxf4tQ/3JBAYNG1oU8gI7rqNgwrxMkWpDB9WU=3D=3B_b=3DFznQQo?= =?utf-8?q?4S0zkpk+3TpNcBeZUeWbZj5O1xdtmMzdj0PuFoP7lzPDyIdbspH2QEJj7ezRovEQg?= =?utf-8?q?1UCIQ5PIw/aySGRhkWEgjdoADPZQ9TH5Pxk9gcAlImIGm8GJ+1pnD+fL+xO7cIsl+?= =?utf-8?q?ojuMrLfVwZmZHMvgPgDecCgf0luoQ9T1/2A=3D?=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.163.140) by HE1PR07MB3244.eurprd07.prod.outlook.com (10.170.246.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.5; Wed, 4 Mar 2020 11:11:24 +0000
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::4d32:e953:5cf9:b55e]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::4d32:e953:5cf9:b55e%6]) with mapi id 15.20.2793.011; Wed, 4 Mar 2020 11:11:24 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] WGLC for draft-ietf-lake-reqs-01
Thread-Index: AQHV6MwfpoQpCxgEvkuW+iJEnj1xX6gl1cQAgAEnDIA=
Date: Wed, 4 Mar 2020 11:11:24 +0000
Message-ID: <2354B114-F555-4069-921E-B5C7A1223721@ericsson.com>
References: <b7c084b0-8489-5c05-046d-33aa70c85b94@cs.tcd.ie> <5a7f6cbe-4e5d-043c-d1a8-0b64633b1506@cs.tcd.ie>
In-Reply-To: <5a7f6cbe-4e5d-043c-d1a8-0b64633b1506@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [213.89.246.8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a7a2edb6-471f-4877-6aa8-08d7c02cc729
x-ms-traffictypediagnostic: HE1PR07MB3244:
x-microsoft-antispam-prvs: =?utf-8?q?=3CHE1PR07MB3244E4762150397A43755856F4E?= =?utf-8?q?50=40HE1PR07MB3244=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-forefront-prvs: 0332AACBC3
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDM5ODYwNDAwMDAyKSgxMzYwMDMpKDM0NjAwMikoMzk2?= =?utf-8?b?MDAzKSgzNzYwMDIpKDE5OTAwNCkoMTg5MDAzKSgyOTYwMDIpKDcxMjAwNDAw?= =?utf-8?b?MDAxKSgzNjc1NjAwMykoMzA4NjQwMDMpKDMzNjU2MDAyKSg2Njk0NjAwNyko?= =?utf-8?q?26005=29=2866476007=29=2885182001=29=2864756008=29=2866446008=29?= =?utf-8?b?KDY2NTU2MDA4KSgyOTA2MDAyKSg4NjM2MjAwMSkoMzE2MDAyKSg2NjU3NDAxMiko?= =?utf-8?q?81166006=29=28186003=29=288676002=29=2885202003=29=285660300002?= =?utf-8?b?KSgxMTAxMzYwMDUpKDY0ODYwMDIpKDg5MzYwMDIpKDQ3ODYwMDAwMSkoNjUx?= =?utf-8?b?MjAwNykoMjYxNjAwNSkoOTY2MDA1KSg4MTE1NjAxNCkoNzYxMTYwMDYpKDY1?= =?utf-8?q?06007=29=2815398625002=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3244; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?/TtWUTiT7vnNE95P7q4VFvTdqcFCsFU?= =?utf-8?q?KSudAzz1MgaxDK+Zu4zMhK/wXaU2fnSG8xujF8TJBICVwCuJq14mcRiaO3y8KHv4j?= =?utf-8?q?/1DlktHhdfGPHNclKTd1c9ZIJHmFnxZPcGPFxcGUtQCfbt0H8JNBTnKZby402ZY+X?= =?utf-8?q?5vR8aCm0f1HUSdZxL2HaWBgFxzGx25IBa75Lw1aYT7hFHNaHsuBoeruw/09mHA/T0?= =?utf-8?q?gUg0hYneXfgJqL6fznHN/hUHjC/8QWDDsD+bj83T4+WL1v1F6ku9L6idCP09SpxER?= =?utf-8?q?cEOdj+2cTnLncr92Fq+LskGbGWtkTI4j05CjwYwmvM06+gq3Q3bIqqpDHrd9VWTqF?= =?utf-8?q?NQNHbRLD34YqF1VL3k/h6HOrwMAzT8eaOFlwOJa7UjFjMII022UFkkpGVYxEHd+gd?= =?utf-8?q?ViH0a/blAG5LhTBlQ0fzT3pQ3Mr3n/BuCrDDmuNVRh878ZHeeYtF2mvq+ag4MM/zF?= =?utf-8?q?je3ni+Iw5v+NEesUgEb/eUUDZVqf1Qr2DJ/CM8qIplJrb0G4GFbksyULtueBsPuBT?= =?utf-8?q?Af8rBlh8qgD2IIhDAcx19sMWA?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?Fae6FMgvxrDbyV0jNLDtblqr+e5FRd?= =?utf-8?q?xUPNDLwpCTb/HLk2Q/Xx+/yF0h5zdiwmYF9LNpdGiEcMeHt1P19XgBZm8uPRQHgJh?= =?utf-8?q?lhtm6GWNNj7jVYPSxFriJXz2AFuvHnVt9hntIdrBIHYArQfBasK5puQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <6A2819012A46134B87375F564EEC2C91@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7a2edb6-471f-4877-6aa8-08d7c02cc729
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2020 11:11:24.7119 (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: =?utf-8?q?PS92yq+pkedUNZ7toAuS8?= =?utf-8?q?N8uBCspmM9rxZ01RNpzfGmpq41oo39/EqNUVYkHlPcsXiS+ykBWqdGU3WnytzDD+/?= =?utf-8?q?gkArMeivJ4NOdpkzvtx6I=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3244
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/L_s7VfLZz1jb9FGrPU_BWBi0GME>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
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, 04 Mar 2020 11:11:31 -0000

Hi Stephen,

Sorry for the delay, I was on vacation last week. 

Thanks for the review,  comments inline.  I made two PRs, one for the non-editorial, another for the editorials and nits:
https://github.com/lake-wg/reqs/pull/17
https://github.com/lake-wg/reqs/pull/18
	
Göran


On 2020-02-21, 17:27, "Lake on behalf of Stephen Farrell" <lake-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:
    
    #1. Is section 3 intended to be all that an AKE designer
    needs to cross-check against their design? That doesn't
    seem to be true at the moment. For example, 2.3 now calls
    for KCI, but that's not mentioned in section 3.  If section
    3 is not intended to be that, then what's the benefit in
    having it? Might be easiest to just delete it since the
    draft isn't that long.

<GS> Good point, section 3 removed.
    
    #2. 2.1: The Sender ID as described in RFC8613, section 3.2
    has additional uniqueness requirements not (re-)stated
    here that aim to protect against nonce re-use in the AEAD.
    Do those requirements apply and/or need to be stated here?
    (I'm not sure they do, as I just quickly looked at 8613,
    so this is just a question.)

<GS> We were hesitant to bring in the full uniqueness requirement, since it introduces terms that are not needed for the requirements, like e.g. "ID Context".  I added sub-bullet to try it out, is that better?

"   Sender IDs are expected to be unique for a given Master Secret, more precisely the quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be unique, see Section 3.3. of [RFC8613]."
    
    #3. 2.1: says "COSE... shall therefore be used also by the
    AKE" - is that too strong? Perhaps all we need to say is
    that it must be possible for an AKE meeting these
    requirements to use COSE? The statement as-is could be
    considered a showstopper for a claim that ctls can meet
    these requirements, which seems like a bad plan.  An editing
    pass to check that we're not stating requirements that can't
    really be met by ctls may be a good idea I'd say.  (The 3rd
    bullet in section 3 also states this requirement.)

<GS> As is mentioned in the same paragraph there are several reasons for requiring COSE to be used. COSE already provides the crypto primitives for OSCORE, schemes for standardized compact identification of credentials and algorithms for OSCORE and the AKE, and an extension point for new schemes. One main target for LAKE are devices with an existing OSCORE and COSE implementation and this requirement avoids duplicating implementation or representation of algorithms etc. for reduced storage and maintenance.

I have two other concerns with this comment:
1. It is not clear to me that "can't be met by CTLS" is well defined. 
2. Why should existing solution candidates at all be considered in the formulation of requirements?

Moreover, I find "it must be possible to use COSE" slightly theoretical. It could be interpreted as compliance with that requirement if it is in theory possible to make a mapping, but that could be of little value unless the specification actually defines how COSE algorithms are used for identification of credentials, algorithms and as extension point for new schemes.

Here is a proposed update:

OLD
COSE provides the crypto primitives for OSCORE, and shall therefore be used also by the AKE, for several reasons including maintenance of crypto library. COSE provides identification of credentials and algorithms for OSCORE and the AKE, and an extension point for new schemes.

NEW
COSE provides the crypto primitives for OSCORE. The AKE shall specify how COSE can be reused for identification of credentials and algorithms of the AKE, as extension point for new schemes, and to avoid duplicated maintenance of crypto library.


    #4. 2.1: "It is therefore assumed that the AKE is being
    transported in a protocol that provides reliable
    transport, that can preserve packet ordering and handle
    message duplication, that can perform fragmentation and
    protect against denial of service attacks..." That seems too
    strongly-stated. s/assumed/desirable/ would seem better to
    me. There may also be applications where an unreliable or
    partially-reliable transport is what's needed, e.g. for a
    sensor where we can easily survive the loss of occasional
    cumulative measurements.

<GS> Yes, it must be possible to run the AKE on top of unreliable link layers, but it is not clear that the AKE should have to care about that. Given that there already is a CoAP implemention available the device should make use of that instead of duplicating the functionality in the AKE. Or, alternatively use some other transport protocol X could provides the same features. Independently of which transport protocol that provides these features it should be out of scope for LAKE. Does that make more sense?
    
    #5. 2.2: "the AKE must support different schemes for
    transporting and identifying credentials, including those
    identified in Section 2 of [I-D.ietf-cose-x509]." I seem to
    recall there being some (possibly now expired) IPR in that
    space. It might be worth s/including/such as/ there to give
    some wriggle room in case one of those methods were still
    encumbered.

<GS>Again, the assumption is that COSE is implemented and in use in the device. I think potential encumbering IPR related to a COSE draft and how to handle that should be the responsibility of the COSE WG, not LAKE. Does that sound reasonable?
    
    #6. 2.5: "all the COSE algorithms" - that could do with a
    reference and that IANA registry [7] can change and
    already has quite a few entries - do we really need all of
    those?  HSS-LMS is there for example and no doubt PQC algs
    will be added soonish. Perhaps what we want to say is that
    an AKE meeting these requirements has to be able to
    support negotiation of (some of?) the recommended algorithms
    from [7] or else from equivalent TLS registries?
    
       [1] https://www.iana.org/assignments/cose/cose.xhtml#algorithms

<GS> A reference is added. I think it would defeat the purpose to state here which algorithms are possible to negotiate, as one feature is that this should be extensible. We state elsewhere that, e.g., PQC is out of scope for now. How about this:

OLD
The AKE shall support negotiation of all the COSE algorithms to be used in the AKE and in OSCORE.

NEW
The AKE shall support negotiation of COSE algorithms [ref] to be used in the AKE and in OSCORE.

[ref] https://www.iana.org/assignments/cose/cose.xhtml#algorithms


    
    #7. 2.6: "In the case of public key identities, the AKE is
    required to protect the identity of one of the peers
    against active attackers and the identity of the other peer
    against passive attackers." That's unclear (to me). I think
    you more-or-less mean that "server" or "listening peer"
    identifiers can be probed by active attackers, but that
    "client" or "initiator" identifiers ought not be visible,
    even if the other peer contacted in that case is bogus.  Is
    that it? (If so, e.g. that'd mean that a server cert had
    to be verified before a client cert was sent for client
    auth.) Could that be worded better?

<GS>This is, as far as I understand, the identity protection provided by SIGMA without going into SIGMA. SIGMA-I provides the protection of initiator identity against active attackers since the responder reveals its identity (identifier) first (encrypted by shared secret derived from ephemeral keys) in the message when it authenticates to the initiator. Since the responder identity is encrypted with key derived from ephemeral DH, it is protected against passive attacks but could be subject to MITM. Conversely SIGMA-R protects the responder against active attackers. If this is still unclear, please propose what needs to be worded better.
    
    #8. 2.9: I'm unclear if we are or are not calling for some
    form of DoS mitigation (e.g. a cookie scheme) when under
    excessive load here. There are also trade-offs in terms of
    bytes on the wire vs. external references (e.g. to certs,
    cert-status) where more of the latter can create a DoS
    vector. I wasn't clear what 2.9 was meant to say TBH.
    It's probably ok to leave it there, and not try make
    it perfect but it might equally be ok to just delete
    the section.

<GS>I agree this section is not in in any way extensive, but it was requested to mention DoS. The CoAP Echo option, mentioned in Section 2.1, provides something like a cookie scheme. Your point with DoS against third parties was missing so I substituted "attacks on responder and initiator" with "attacks on responder, initiator and third parties ".    


    editorial:
    
    - abstract: Given the charter of the WG calls for not
    publishing this as an RFC (at least for now, we could
    revisit that later), it may be useful to include a statement
    to that effect in the abstract, so readers don't get
    confused now or later. Perhaps something like: "This draft
    [is in|has completed] a working group last call (WGLC) in
    the LAKE working group.  Post-WGLC, the requirements [will
    be|are] considered sufficiently stable for the working group
    to proceed with its work. It is not currently planned to
    publish this draft as an RFC." (The square-bracketed text
    could be made to match the correct state whenever a revised
    I-D is published.)

<GS> Done.
    
    - intro: there's a mention of OCF without a reference. When
    I went and checked [2] I didn't find the string "OSCORE",
    am I looking in the wrong place? ([2] is 195 pages long
    though, so I may have just missed it;-) [FairHair] now also
    seems to be part of OCF, and I also didn't find the string
    "OSCORE" in [3]. I guess that bit of text needs an update or
    could be deleted?
    
       [2]
    https://openconnectivity.org/specs/OCF_Security_Specification_v2.1.1.pdf
       [3]
    https://openconnectivity.org/wp-content/uploads/2019/11/fairhair-specification-version-10_approved_april-2019.pdf

<GS> Thanks for checking the references. OCF provided requirements on OSCORE during the development and expressed an interest to adopt OSCORE once it had become an RFC which happened in July 2019 (after this text was drafted) but since it is still not include in any reference we can delete that bullet. Fairhair Alliance which is now OCF included OSCORE in their security architecture for IoT in commercial buildings white paper, but that reference is now moved to the OCF domain so I kept the reference but changed to the new location.

    
    - 2.3: KCI and the other threats in that bullet list could
    benefit from references (to avoid AKE designers
    disagreeing on what's meant, which'd be good to avoid
    later). The references below (well, all but one:-), might
    work for those.
    
        [4]
    https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf
        [5] https://arxiv.org/pdf/1902.07550.pdf
        [6]
    https://eu.azcentral.com/story/news/local/southwest-valley/2019/03/10/90-seconds-terror-wildlife-world-zoo-started-jaguar-selfie-litchfield-park/3125031002/
        [7] https://eprint.iacr.org/2019/347

<GS> OK. I left out the jaguar attack though :D
    
    - 2.6: "For certain data we therefore need to make an
    exemption in order to obtain an efficient protocol." I
    don't think you actually need to say that, but if there's a
    desire to say something, maybe better to turn it around, and
    e.g. say "An AKE that protects identifiers is preferable to
    one that does not." (The sentence before already makes the
    point that trade-offs may be needed.)

<GS> Sentence removed.
    
    - 2.10: "per power": in my experience the aspect of radio
    power consumption one would most like to reduce is
    listening time and not transmitting time. This text doesn't
    seem to reflect that.

<GS> Indeed, listening has a high cost, and there are techniques to reduce that cost like time slots, DRX, etc. IIRC, the reason why listening time is omitted is because it is not believed to impact the design of an AKE on application layer. I added some text on this.

    
    very nitty stuff:
    
    - intro, 1st para: be good to have a URL for LAKE somewhere
    in case a reader doesn't know about the WG.

<GS> Done.
    
    - intro: Why the versioning related to other WG charters?
    E.g. the "(-02)" for 6ticsh. Not objecting but seems
    unnecessary.

<GS> This was copied from input to the secdispatch discussion, now versions are removed.
    
    - 2.1: COSE should have a reference on 1st use.

<GS> Done, added reference to CoAP and CBOR too.
    
    - 2.2: "IoT deployments differ..." is a little ambiguous.
    You could mean that they differ from non-IoT deployments
    or that different IoT deployments differ. I guess it's the
    latter. s/differ/differ from one another/ would fix I guess.

<GS> Done.
    
    - 2.2: "Considering the wide variety of deployments the AKE
    must support different schemes for transporting and
    identifying credentials, including those identified in
    Section 2 of [I-D.ietf-cose-x509]." That's not a sentence.
    s/deployments/deployments,/ would make it one:-)

<GS> Done.
    

    - 2.6: It might be good to use "identifier" rather than
    "identity" in a number of places here.

<GS> I find it difficult to do this consistently. There are already a number of terms expressed in terms of "identity". The SIGMA paper speaks of "identity". The requirements are expressed in terms of "identity protection" and "identity misbinding", should we change that to "identifier protection" and "identifier misbinding"? When I've tried I ended up in formulations like "the identifier identifying the identity" and then I gave up. So, not done. Please provide concrete proposal if you think this is worth doing.

    - 2.7: Just a comment in passing:
    [I-D.selander-ace-ake-authz] seems to have a bunch in
    common with ESNI.

<GS> Interesting. I didn't see any implications on any of the drafts though.
    
    - 2.10: (In somewhat self-aggrandising mode:-) a reference
    to RFC8376 might provide some more useful background here.

<GS> Done.
    
    - refs: the URL for the PDF referenced by [LwM2M] is an
    http-schemed URL. Better to use https.

<GS> Done.

    - refs: [FairHair] - the https URL here generates a cert
    error (wrong name in some URL shortener or something)
    
 <GS> Fixed by the updated location for this reference.