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

Göran Selander <goran.selander@ericsson.com> Thu, 05 March 2020 06:32 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 1D2D53A0E04 for <lake@ietfa.amsl.com>; Wed, 4 Mar 2020 22:32:26 -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 stD3A8DfLW0g for <lake@ietfa.amsl.com>; Wed, 4 Mar 2020 22:32:23 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10060.outbound.protection.outlook.com [40.107.1.60]) (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 D3ED03A0E03 for <lake@ietf.org>; Wed, 4 Mar 2020 22:32:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ug8VAKdqh0y4ogzf2t2/GW3mkB/PSGjOg1iI1xwGBzRawx+wxiX9S3PojLsUo58nEYyfZP3mAEvnfLZ6RzqQQFLsN5I024hrwhZNUG2Lh5DDe27vYKe/T78VHkhQ5tHIXwHWwXC6aQvBlhIfps0QkS+C8IFUPu9eBtuDqGWPyHewYsvM25lbQKCnbYEHQjEX+7oL9ZZM9WC0Z4hwFIt8YDzgwYLSiQB5lUpNerTn9M+RK5NZoZp19xwhhAm7Fo209Uah/zUG6+JtkzuOugY4SWyD8aX8aOkLUqSGX/BthayozbKEJ+9vnm0FxpkbrnOGb46RjBiIL96IPk5gJlvPuw==
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-SenderADCheck;bh=U/JX4X6bg3npdMwHEZfrYPBex9Qra1VmbqzM5uCoYck=; b=bJUxEy3MFG5gGclyftiSvaNuQNR++M73sZybtPreb2NtSkw5cFUpNGa5lLHC1Gh264yXgPAqcluzridElo8mrgBfymVgdYQ4Axe2tWytoXykZMTql+IPaOHh6HZtTUOA69wZSSlSzQv3bTiDsjp+T/FWgnh0080kCOFDe74zd5ySO8vFbzKT0i93xV4S6Dr4hOh9B+CmQ57SrugwAmcQ0m5WLbMWFpgucUDV2YgdSgIKXFdnrBi5wbK219pUQ5T9Ej5Pw+x71YJdjXBeJCMhscRJ2Gtq/1DkcFStJCCADPZbJ2UlkPDFghyPAftYB2bh8W//lw/s7Xn0E56HXdY6hw==
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=U/JX4X6bg3npdMwHEZfrYPBex9Qra1VmbqzM5uCoYck=; b=W3NM+jRJtFmMBLJEuu1Z/R8gu7/ayYfsPdFfeNRlVBzFfooGpot+XsRK3U1zQmRm9WsfhamsskzLLo8d44ITh3I5aU0vxtA4WH0Q8vIfLlExgtCf0ZYJSsgX6zFQR8evq91Wy1JdOCsakXHSYjuBS0YHsJ60Cire3hru/IDdLfI=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.163.140) by HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.5; Thu, 5 Mar 2020 06:32:20 +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.013; Thu, 5 Mar 2020 06:32:20 +0000
From: Göran Selander <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+iJEnj1xX6gl1cQAgAEnDICAEqE7gA==
Date: Thu, 05 Mar 2020 06:32:20 +0000
Message-ID: <C4F22E94-112A-4C0A-B131-B1FC997ECCDE@ericsson.com>
References: <b7c084b0-8489-5c05-046d-33aa70c85b94@cs.tcd.ie> <5a7f6cbe-4e5d-043c-d1a8-0b64633b1506@cs.tcd.ie> <2354B114-F555-4069-921E-B5C7A1223721@ericsson.com>
In-Reply-To: <2354B114-F555-4069-921E-B5C7A1223721@ericsson.com>
Accept-Language: en-US
Content-Language: sv-SE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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: cc3028de-bdb7-4e9c-d7e1-08d7c0cef501
x-ms-traffictypediagnostic: HE1PR07MB3242:
x-microsoft-antispam-prvs: <HE1PR07MB3242E97A513D9050C5A8963FF4E20@HE1PR07MB3242.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1751;
x-forefront-prvs: 03333C607F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(136003)(366004)(376002)(199004)(189003)(26005)(33656002)(966005)(66574012)(71200400001)(478600001)(85202003)(186003)(316002)(6512007)(296002)(36756003)(86362001)(81156014)(2906002)(8936002)(6486002)(8676002)(81166006)(85182001)(110136005)(66476007)(66556008)(66616009)(66446008)(66946007)(5660300002)(64756008)(6506007)(76116006)(30864003)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3242; 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: GqivWx2ngd7xu+HWV4G+L1B7gXcBzj7RS3cEEcFs+GQvP84LhiI48Jm+JMYwJ7A9IGaHIbohRFsgzOIq916n5JBNhjhGR6FkS0J/dOlk24igKgZ2HFrE1BCIoqZvbaQc035Xs6VWmVrbHCKgIdae+UWiPgS6GMziFSQn8ZZ+ew5Pu73n25gTmgxDQjD+M6yOelzaMhS9NdTmPmAUxNYauFBVJAakdnoYB8oAewZlyNmoQqO979sWR65pjplkee0KXCakDdG2waKSY+KlHX5tKI6M097aKOeNApYzQ9+ihI39Q34Ep7XCUcuKx8SlQs2uW91LuYtJyqbXd2M74XA5TQcYYNzyXZwmHfEq4o3xLuQNTAZ8wfMuAmr1ItL9mBYyI5K/1QZvxSezjEL54jP39eZHrslY9jsIyRzZuiOKYWQpFj/deJRiSzPGuN7ErOHmiLTAGmIMVViSSDJuGWCh0Jw6zNE+BbGi0IuS8N7RiiPW+Sbq6RbkspLOpFAsv0wR6Abbu6TfpC6/Scwe0umHeA==
x-ms-exchange-antispam-messagedata: yOVPQXeF0vooT1MA4Q7hSvE4XwPOU5eFzGKeJcvwJliVk4cOLMmUdtUofzPt2HSXzhARyET2J29+B+nsqDDGcGZrfUCydJ7d71SPJUJDoqnX20pNbJPyVHPHK8Z5EIVyhw0noh4gVOElF/573e9aCw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="Apple-Mail-73A2A967-08AD-4271-85CA-80C073036287"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc3028de-bdb7-4e9c-d7e1-08d7c0cef501
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 06:32:20.1040 (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: dh1QsJ9xIGIfRZtNEg7ooOj4Rxw0wFVZsqhtrLIsiTw0pziA0X9yXXEBTr0h57kvZX1Cy26UTh8ceez1J4sZbsNhGFUv4dgRCw/5rZU6hP4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3242
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/GwWiIfWQh7U5aYLTfuaLNMIUwQc>
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: Thu, 05 Mar 2020 06:32:26 -0000

Hi Stephen,

I was made aware of that there is a minor difference in the proposed update written in the mail and in the PR in response to comment #3. 

I copied some of the changes to the draft from the PR to the mail for easy access, but that of course opened up for different versions - bad idea. 

Sorry about that. Please disregard the OLD/NEW and read the PRs. 

Göran

> 4 mars 2020 kl. 12:12 skrev Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>:
> 
> 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://protect2.fireeye.com/v1/url?k=75ec52db-2966992f-75ec1240-86cd58c48020-6fad257f20bb0616&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Freqs%2Fpull%2F17
> https://protect2.fireeye.com/v1/url?k=3c22b196-60a87a62-3c22f10d-86cd58c48020-3d4caf50a871db19&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Freqs%2Fpull%2F18
> 
> 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://protect2.fireeye.com/v1/url?k=bfcc30c8-e346fb3c-bfcc7053-86cd58c48020-a6ee78aa0ea1898d&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fopenconnectivity.org%2Fspecs%2FOCF_Security_Specification_v2.1.1.pdf
>      [3]
>   https://protect2.fireeye.com/v1/url?k=7ea70362-222dc896-7ea743f9-86cd58c48020-387f3301be17e2d1&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fopenconnectivity.org%2Fwp-content%2Fuploads%2F2019%2F11%2Ffairhair-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://protect2.fireeye.com/v1/url?k=209283f4-7c184800-2092c36f-86cd58c48020-9a49deb13e0e55ca&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347
> 
> <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.
> 
> 
> -- 
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake