Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Sun, 22 December 2019 03:49 UTC
Return-Path: <pkampana@cisco.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16612008B; Sat, 21 Dec 2019 19:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OEzT4ue+; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=njb5Wxe7
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 SiEjETdSRsZV; Sat, 21 Dec 2019 19:49:12 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53BD120072; Sat, 21 Dec 2019 19:49:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15885; q=dns/txt; s=iport; t=1576986552; x=1578196152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H7HLJPPTFMohAHcrO9mz46CXJGLS6sJS25n82DslCd4=; b=OEzT4ue+WGfJmU3GuSEltVAGtsaJWXPlGDwTM8Th72/baYXiEiRHpcHg /y87R9qgbaCKdNSMUeZxf2LU/gh7+8e2gSf1XmYT/RKzTf2in/SHO0+i/ IvzDxH96EA6dXsutPRnQ4l0gElgnMc+rLu/ZxVDHwJU93nL3EYw8SP8vd o=;
X-Files: smime.p7s : 4024
IronPort-PHdr: 9a23:xZ3Gkhz26WmXhS7XCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DCCQBM5/5d/4cNJK1cCYQPJAUnBWwrLSAECyqEB4NGA4p2gl+YCIFCgRADVAIHAQEBCQMBARgLCgIBAYRAAoIcJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQQBARARHQEBJQcLAQsEAgEIEQQBASsCAgIlCx0IAgQBCQQFCAYUgjVMgXlNAx8PAQIMoDQCgTiIYXWBMoJ+AQEFgTUBE0GDFRiCBQcDBoE2gVOKKQ4PGoFBP4ERR4JMPoJkAQEBAgGBLAEICgEJGDCCXjKCLI01CAyCcYgZhx+OLnQKgjSDYYI3gRuEdEeJRoJGh3uQFo5SiFKSBAIEAgQFAg4BAQWBaSJnWBEIcBU7gmxQGA1XjEYYFYM7hRSFP3QBgSePUYFTXwEB
X-IronPort-AV: E=Sophos;i="5.69,342,1571702400"; d="p7s'?scan'208";a="395533292"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Dec 2019 03:49:10 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xBM3nAkF001033 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Dec 2019 03:49:10 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 21:49:10 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 21:49:09 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 21 Dec 2019 22:49:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3HKfD283llBdKFxY5sbRV8hnfhS+ZyPzyZLmt/yue7m/XGXNTmxdN8pcQBxEjVYxleJnYspEEvNvtPmq/bJemVL2tF83da89qnIq1tLTJLQl698Mdc9eYMdgQFUiuR6NG+iosZRBF0nH1WjdDTPkdO63iUR8cFL7mE1qlMKM/MWlFAkZ1Lq+iMNuKAPF9x4v5CBG2CFOebgpk2PEznmpnm/FclptIm01/9wBVtVgxt6hKm9SDZVqybSWiSnKsak2llnCeQ3rkOwPUYpR+1A8bXsjgYgMTxcMNT4W1a/q8L3AjKpquuntBPAWNdHrwqY58Vs5Eiwu4KBRgg/zWbL0g==
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=pWRQhy+TzCBeGVjU8Zyw6arJ0xdO8sNZkTA6DaJg+2s=; b=l4KRWZVtiLwpmzTpokU83SW0qqyesM8W7TBzEofAJvrBkN1zhbGCXILltG4PGNlja1WOGWS0YH6SooXV27HbC58NitUu/+amuR6Tp+iKTDgFF+i5jk6mfDp+6JVQ15ROmcrgdSDNTChq/lx+4pZLnqkZjWfPJtJrTBiCE2ZU3DYWi74MWrMZAZ0h3RE2RKVFVRsHGw+X0qMwtTLFIbutWT+nkRIjGHKm/lHmdy2ndlu6vZB2aL3VZ+gfGtWolLWwMiAV5SMtzOS00rXb5Go/1CREbNEcVYiEiz2yIQmpzkmI7uwhRz6LDPp0SswQc3s2+kTPUWsHr3LjTlRfsAGAYA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pWRQhy+TzCBeGVjU8Zyw6arJ0xdO8sNZkTA6DaJg+2s=; b=njb5Wxe7kHey5GUp3Jw/E2tSiJ+oDeauAvK6NO8L1MfqXq9D5nsbObY5N2uaZ9+eCUQuKqaAs/kvb6IsBoZ2VNJ7f6h++plBdg/+iYWlsGYfCeLlPrOktCignZawbGXcyN9xqTpz/1ohMfIoMZN6Ue1vqqIOvKS357IM/MullBQ=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2738.namprd11.prod.outlook.com (52.135.245.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Sun, 22 Dec 2019 03:49:08 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.017; Sun, 22 Dec 2019 03:49:08 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ace-coap-est@ietf.org" <draft-ietf-ace-coap-est@ietf.org>, "ietf@augustcellars.com" <ietf@augustcellars.com>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
Thread-Index: AQHVtIXtXsiUGCzH10qa4vZMC+mOsqfFhtmQ
Date: Sun, 22 Dec 2019 03:49:08 +0000
Message-ID: <BN7PR11MB25476B4B22CED73F2DA25A4BC92F0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com>
In-Reply-To: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com;
x-originating-ip: [2001:420:c0c4:1004::3d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a34f25f5-b359-470f-f0bb-08d78691e61d
x-ms-traffictypediagnostic: BN7PR11MB2738:
x-microsoft-antispam-prvs: <BN7PR11MB273838FB45D390148E6D3D85C92F0@BN7PR11MB2738.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 02596AB7DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(376002)(39860400002)(346002)(396003)(136003)(366004)(199004)(189003)(13464003)(76116006)(5660300002)(8936002)(316002)(54906003)(66476007)(66556008)(186003)(478600001)(2906002)(9686003)(66616009)(81166006)(81156014)(52536014)(33656002)(86362001)(53546011)(6506007)(55016002)(7696005)(66946007)(4326008)(64756008)(71200400001)(110136005)(8676002)(66446008)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2738; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /Dqyew+P71rdBERG1KFK/yHCj2MXJe33fyq80tWYnVGepY/kYAKtBfGZBcX7wP9n4couGNJKYRQY/Y8COUrlowHycH8c/IA1nSjq4eHxpuv5Zh65mf/v/5gSvg+w3QGly6L4qIDfDGwT2AzZIRvD3oqSO9fLPY52crqv56dmRL5cU9CUZmxg1lB6L/9zHtlKKmJf6oih1kRqO65wPqGzRLdzz+wpqWnqfhKNcp7Mfqjuk9YmZZ1GS2v4nbGjqTfeVf5XwJ6yG6FW1z2Onxa4tYeqMtrmCkt6+cC0wvrTTpjnKDHIemu2VdffIVHodqdluLSIb2kysICrnkNCaJ185H5QWonp5i9xFvLvfoc+xASUFB76aMd/Y/quMoFtiHbE9u/ntqmzMeE1CFJsDYXVQpgC3Ft8eywa/efs1Yt2xZ9qhkJHZlLRXGztKIO8xhKaCiX1LEugJm8ozqAe86qRzfTfBMhEkM04LNgh8FmWUjRjJuenVxUt5vCA+WnCHozSrJYXaQZ9vW9xn/dHn/fdWVhFR9KtepJBfRPVRsD7VArpq5iIl9Kr1gl7tsD8+s4t/rSopUV32s0qgvBhLFyBB1E0GQ5Hnx9N+YMc7DEcNoQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_002A_01D5B850.D9FFC490"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a34f25f5-b359-470f-f0bb-08d78691e61d
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2019 03:49:08.4086 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RTldhneRcDQw87uAxMj6QfQozg7ufIocChmbvesW/DVFqrGbVxbKhqYKyPRjUmZup2Fh0UHGWAMztdhjrLYybw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2738
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/s4Ki3vmU2Y8eJ73lkK0qd9HyipY>
Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Dec 2019 03:49:15 -0000
Hi Barry, Thank you for the thorough review. We are tracking your feedback and our responses in a git issue https://github.com/SanKumar2015/EST-coaps/issues/153 We mostly confirm all your minor text changes and nit fixes. The TBD one we will not fix as we are waiting on IANA. Let us know if something does not make sense. Rgs, Panos -----Original Message----- From: Ace <ace-bounces@ietf.org> On Behalf Of Barry Leiba via Datatracker Sent: Monday, December 16, 2019 9:59 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this — a useful document. I have a bunch of comments, but they’re all editorial. Please consider them, but there’s not a need to give a detailed reply. -- Section 4 -- In that case, the server MAY want to authenticate a client certificate against its trust store although the certificate is expired (Section 10). Total nit: Why "want to"? Why not "server MAY authenticate"? As described in Section 2.1 of [RFC5272] proof-of-identity refers to a value that can be used to prove that the private key corresponding to the certified public key is in the possession of and can be used by an end-entity or client. I find the passive voice to be quite awkward here, and suggest making it active: NEW As described in Section 2.1 of [RFC5272], proof-of-identity refers to a value that can be used to prove that an end-entity or client is in possession of and can use the private key corresponding to the certified public key. END the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 4.2.6 of [RFC6347]). I know this wording is directly from 6347, but I think it's unclear and would like to suggest an alternative. The "as a single fragment" part is odd, because I think what it's really saying is that it's computed as if it had not been fragmented. My suggestion is to change it thus (and similarly for the next paragraph after): NEW the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed on each reassembled message, as if each handshake message had not been fragmented (Section 4.2.6 of [RFC6347]). END If that's not correct, please take that as further evidence that it's unclear, and adjust accordingly. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions which was not the case with [RFC7030]. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. Two total nits: a. Comma before "which", please. b. The "for example" needs some rewording to make it work: NEW For example, if an EST csrattrs request is followed by a simpleenroll request, both can use the same authenticated DTLS connection. END -- Section 5.1 -- EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible (1) rigid ones where the address and the supported functions of the EST server(s) are known, and (2) flexible one where the EST server and it supported functions need to be discovered. This needs a colon (:) after "possible", a comma after "rigid ones", "a" before "flexible one", another comma after "flexible one", and make it "its supported". -- Section 5.5 -- Similarly, 2.04 is used in successfull response to EST-coaps POST requests (/sen, /sren, /skg, /skc). There's odd spacing here; please fix it. And "successful" is misspelled. -- Section 5.7 -- If the server is very slow (i.e., minutes) in providing the response (i.e., when a manual intervention is needed), I think you mean "e.g." for both of those, evidence for my general aversion to using Latin abbreviations that many people don't fully understand. It also feels odd to have the two examples separated in this way. I suggest this: NEW If the server is very slow in providing the response (for example, manual intervention is required and it could take minutes for it to respond), END it SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max- Age Option to indicate the time the client SHOULD wait to request the content later. Perhaps, "to indicate the time the client SHOULD wait before sending another request to obtain the content." ? After a delay of Max-Age, the client SHOULD resend the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server responds with the certificate or the client abandons the request for other reasons. That last sentence reads very strangely to me. It SHOULD keep resending the request until it decides to stop? What does that actually mean? Maybe what you're really trying to say is something like this?: NEW As long as the server continues responding with response code 5.03 (Service Unavailable) with a Max-Age Option, the client will continue to delay for Max-Age and then resend the enrollment request until the server responds with the certificate or the client abandons the request for policy or other reasons. END -- Section 5.8 -- In scenarios where it is desirable that the server generates the private key, server-side key generation is available. This seems like a content-free sentence. Maybe this?: NEW Private keys can be generated on the server. Scenarios where that makes sense include those where it is considered more secure... END Of course, that does not eliminate the need for proper random numbers in various protocols like (D)TLS (Section 10.1). May I suggest this?: NEW As always, it is necessary to use proper random numbers in various protocols such as (D)TLS (Section 10.1). END server or proxy to generate the private key and the certificate which are transferred back to the client Needs a comma before "which". or the asymmetric keypair establishment method is out of scope of the specification. "of this specification". [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.3) . The two representations More odd spacing. Dependent on the request, the private key can be in unprotected PKCS#8 [RFC5958] format "Depending upon the request" In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Long sentence that needs punctuation: comma after "operations", comma before "which", comma before "and". Also, I would move "(in the CSR)" a few words later, after "public key". -- Section 7 -- It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). Odd spacing, again. But "it is recommended to follow" is also odd English. I suggest making this active, rather than passive, thus: NEW Implementations should follow the default CoAP configuration parameters ([RFC7252]). END I don't think the "based on experiments" bit adds anything, but if you want to keep it you can prepend "Experiments have shown that" to my suggestion. -- Section 9.1 -- Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" just a flag to remind people that it hadn't been formally allocated yet? — Section 10.1 — It is important to note that sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs are not available on many constrained devices, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. The sentence order is wrong here. For example, mouse movement is not a constrained device. The correct order is more like this: NEW It is important to note that, as pointed out in [PsQs], sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, are not available on many constrained devices. END _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
- [Ace] Barry Leiba's No Objection on draft-ietf-ac… Barry Leiba via Datatracker
- Re: [Ace] Barry Leiba's No Objection on draft-iet… Panos Kampanakis (pkampana)
- Re: [Ace] Barry Leiba's No Objection on draft-iet… Panos Kampanakis (pkampana)
- Re: [Ace] Barry Leiba's No Objection on draft-iet… Barry Leiba