Re: [Ace] AD review of draft-ietf-ace-coap-est-12
Peter van der Stok <stokcons@bbhmail.nl> Mon, 02 September 2019 12:47 UTC
Return-Path: <stokcons@bbhmail.nl>
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 5B28A120142; Mon, 2 Sep 2019 05:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl
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 CdZUcqJl0UZV; Mon, 2 Sep 2019 05:47:13 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C141120110; Mon, 2 Sep 2019 05:47:12 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 7DA78100E86C6; Mon, 2 Sep 2019 12:47:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=+puPyBrvnGQumGPk++ gKXJGxOIhG2f2wS/kiQ2VwIZs=; b=CMu672s+fh+BGAfMmHNdYpCN42e3RteY2Z 2RgvtBKz/qyevGzYBbKQsHMxXq69j+6ATxIs8sH0c7umKH6SzPBKnjP4+Si/j//t FBIi04MJGkuO4gx1aUUuTR/Im8OwWoDrDyfCBdqpxHzAPJkplep30SB5rK0JP3tl 4E2f9gMME=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::, RULES_HIT:41:69:152:327:355:379:582:599:960:962:967:973:978:982:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1616:1712:1730:1776:1792:2197:2198:2199:2200:2553:2559:2562:2689:2692:2693:2731:2739:2740:2892:2898:2900:2902:2909:2911:2924:2926:3138:3139:3140:3141:3142:3622:3834:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4425:4605:4860:5007:6117:6119:6261:6659:6678:6690:7774:7808:7875:7903:7904:8603:9010:10848:10946:10954:11233:11657:11658:11914:12043:12109:12114:12291:12295:12438:12555:12663:12679:12683:12895:13145:13160:13161:13190:13200:13229:13230:13869:13870:14096:14110:21060:21063:21080:21220:21433:21450:21451:21611:21625:21740:21939:30005:30012:30018:30025:30034:30041:30045:30054:30069:30070:30075:30080:30083:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, Domain
X-HE-Tag: card43_3ead8ab5db93d
X-Filterd-Recvd-Size: 36688
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Mon, 2 Sep 2019 12:47:10 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_b978f585753a6193b20c0bb6854d622a"
Date: Mon, 02 Sep 2019 14:47:10 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: consultancy@vanderstok.org, Jim Schaad <ietf@augustcellars.com>, draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <20190901204340.GG27269@kduck.mit.edu>
References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> <edcbc2a243cc7118e35aec77b2e1599c@bbhmail.nl> <20190901204340.GG27269@kduck.mit.edu>
Message-ID: <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [5.206.216.229]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/JgmG4hge48Pg6KXLjo6c0qUPnBA>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12
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: Mon, 02 Sep 2019 12:47:17 -0000
Hi Ben, Below some additional reactions to your review. In some parts the term "suggest" is used, meaning that I am not sure of the correctness of my reaction. A confirmation/denial would be appreciated in those cases. My co-authors can always improve my changes. To-morrow I hope to do the follow-up. many thanks, peter ________________________________________________________________ Section 4 As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite nit: I do see RFC 7925 in the subject heading, but the lead-in here is still a bit jarring. Without some statement in this document to that effect, RFC 7925 is not binding on the protocol specified in this document, so I think it's better to say something like "In accordance with", or even to flat out state that "this document conforms to the DTLS 1.2 profile specified in RFC 7925". <pvds> done, used: In accordance with sections … </pvds> DTLS 1.2 implementations must use the Supported Elliptic Curves and Supported Point Formats Extensions in [RFC8422]. Uncompressed point format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13] implementations differ from DTLS 1.2 because they do not support point format negotiation in favor of a single point format for each curve. Thus, support for DTLS 1.3 does not mandate point format extensions and negotiation. DTLS 1.3 uses the "supported_groups" extension in contrast to Supported Elliptic Curves for 1.2; we should mention that disparity as well. <pvds> added at the end of the paragraph </pvds> o a previously issued client certificate (e.g., an existing certificate issued by the EST CA); this could be a common case for simple re-enrollment of clients. Is "re-enrollment" intended to cover renewal operations? <pvds>RFC7030 states: "An EST client can renew/rekey its existing client certificate by submitting a re-enrollment request to an EST server." Do you want that emphasized more in the draft? </pvds> o a previously installed certificate (e.g., manufacturer IDevID [ieee802.1ar] or a certificate issued by some other party); the server is expected to trust that certificate. IDevID's are "trust" can cover a lot of things, many of which we don't really need here; would "expected to be able to validate" suffice? <pvds> s/is expected to trust that certificate/ can use the certificate for DTLS client Authentication/ </pvds> 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 public key is in the possession of and can be used by an end- entity or client. Additionally, channel-binding information can link nit: "the certified public key", I think, since the certificate is what binds the identity to the public key. Also, this sentence is a bit awkward, though I don't have any concrete rewording suggestions at present. <pvds>s/public key/certified public key/ Suggestion, is this better?: "a client provides proof of identity by proving that it possesses the private key corresponding with the certified public key" Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other. In some cases, like NAT rebinding, keeping the state of a connection is not possible when devices sleep for extended periods of time. In such occasions, [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can eliminate the need for new handshake and its additional cost. Do we also want to mention DTLS 1.3 session resumption here as less expensive than a full handshake? It's not as cheap as "just keep using the same connection ID", of course, but has somewhat different other properties. <pvds> thanks, added: "additional cost; or DTLS 1.3 session resumption provides a less costly alternative than re-doing a full DTLS handshake." </pvds> Section 5 o Simple enroll and re-enroll for a CA to sign public client identity key. nit(?): is this "public client identity key" or "client identity public key" or something else? <pvds>by reducing the txt's target, I suggest: s/public client identity key/client certificate/ </pvds> o Certificate Signing Request (CSR) attribute messages that inform the client of the fields to include in a CSR. nit: "informs" <pvds> yep, thanks </pvds> o Server-side key generation messages to provide a private client identity key when the client choses so. (similar nit(?) as above) <pvds>also reducing the text's target: s/provide a private client identity key/provide the client with a new private key/ </pvds> Section 5.1 With the current text, I expect us to get several IESG questions about "why do you have both discovery and well-known URIs?". I think we need to treat this more prominently in the first few paragraphs of the section, perhaps just after we discuss the short-est strings, so we could tie into the constrained nature of things and how some devices may need to hardcode assumptions about the endpoint location. <pvds> I suggest the following starting text: "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. For both types of installations, saving header space….." </pvds> Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and corresponding paths which are supported by EST. Table 1 provides the mapping from the EST URI path to the shorter EST-coaps URI path. Our table has the entries in a different order than 7030's table. <pvds> correct, has been modified </pvds> We also don't say anything about the (lack of the) fullcmc endpoint. <pvds>/fullcmc is added in the table with "n.a." as short value </pvds> The serverkeygen endpoints could perhaps have some notation to indicate that the private key is always returned, in addition to the PKCS#7 vs. pkix-cert question that distinguishes skg and skc. <pvds>after "…..an /skc request.", the following text is added: "In both cases a private key MUST be returned." </pvds> The /skg message is the EST /serverkeygen equivalent where the client requests for a certificate in PKCS#7 format and a private key. If nit: s/requests for a/requests a/ <pvds>done</pvds> Clients and servers MUST support the short resource EST-coaps URIs. Are they expected to also support the long EST URIs over CoAP? <pvds> It was undecided whether we should add: "The corresponding longer URIs from <xref target="RFC7030"/> MAY be supported." </pvds> The first three lines of the discovery response above MUST be returned if the server supports resource discovery. The last three It may be worth listing out ace.est.crts, ace.est.sen, and ace.est.sren explicitly for clarity (especially since line breaks are "only for readability") <pvds> after "the first three lines" added ",describing ace.est.crts, ace.est.sen, and ace.est.sren," </pvds> lines are only included if the corresponding EST functions are implemented. The Content-Formats in the response allow the client to request one that is supported by the server. These are the values that would be sent in the client request with an Accept option. It seems that these specific values (or a subset thereof) are mandatory; a forward reference might be in order. <pvds> "Added : "(see table 2)" Section 5.2 Did we consider merging this table with Table 1? <pvds> The functions of the tables are different. It fits the progress of the text. Merging will probably mean more forward references. Unless two tables are too boring, I suggest to leave as is. </pvds> Section 5.2 While [RFC7030] permits a number of these functions to be used without authentication, this specification requires that the client MUST be authenticated for all functions. Perhaps this divergence from 7030 should be noted more prominently, perhaps in the section title or a dedicated "Differences from RFC 7030" section? <pvds> Suggestion to move this phrase to section 5 just before section 5.1? </pvds> Section 5.3 EST-coaps is designed for low-resource devices and hence does not need to send Base64-encoded data. Simple binary is more efficient (30% smaller payload) and well supported by CoAP. Thus, the payload for a given Media-Type follows the ASN.1 structure of the Media-Type and is transported in binary format. This last sentence is only true when scoped to this document, for which all the content we're handling is specified using ASN.1. I don't know whether we want to tweak the wording to reflect that or not, though. Also, we probably should say DER-encoded ASN.1 structure (or BER? I'd have to check what the requirements are) since ASN.1 is just the abstract syntax and not the encoding rules. <pvds> s/payload/payload for DER-encoded ASN.1/ </pvds> When the client makes an /skc request the certificate returned with the private key is a single X.509 certificate (not a PKCS#7 container) with Content-Format identifier TBD287 (0x011F) instead of 281. In cases where the private key is encrypted with CMS (as explained in Section 5.8) the Content-Format identifier is 280 (0x0118) instead of 284. The key and certificate representations are ASN.1 encoded in binary format. An example is shown in Appendix A.3. I think these relationships might be more clear in tabular form; I dind't really understand the scheme at this point in the document, and needed to get a ways further in before it really "clicked". <pvds> the following table is added. Is that sufficient? +----------+-----------------+-----------------+ | Function | Response part 1 | Response part 2 | +----------+-----------------+-----------------+ | /skg | 284 | 281 | | /skc | 280 | TBD287 | +----------+-----------------+-----------------+ Table 3: response content formats for skg and skc </pvds> Section 5.4 o EST-coaps servers sometimes need to provide delayed responses which are conveyed with an empty ACK or an ACK containing response code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED nit: the response itself (delayed or not) is not in the ACK, so maybe "the need for which is conveyed". <pvds> s/responses which are conveyed with an/which are preceded by an immediately returned/ Section 5.6 layer. In addition, invokers residing on a 6LoWPAN over IEEE 802.15.4 [ieee802.15.4] network should attempt to size CoAP messages such that each DTLS record will fit within one or two IEEE 802.15.4 frames. Is this intended to be a normative SHOULD? If not, it feels like we need a reference or justification. <pvds> s/should attempt/are recommended/ </pvds> Section 5.7 certificate to the client after a short delay. If the certificate response is large, the server will need more than one Block2 blocks to transfer it. nit: "Block2 block" singular <pvds> thanks, done </pvds> POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> <-- (ACK) (1:0/1/256) (2.31 Continue) Where is this notation documented? (Is Appendix B.1 of this document the first place it's introduced?) We need some kind of reference on first usage. <pvds> Just before figure 2 the following phrase is added: "The notation of figure 2 is explained in section B.1" </pvds> If the server is very slow (i.e. minutes) in providing the response (i.e. when a manual intervention is needed), he SHOULD respond with nit: RFC style puts commas after (and before) "i.e." and "e.g.". <pvds>done everywhere </pvds> 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 for other reasons. nit: the transitive verb "abandons" has no direct object <pvds>abandons the request </pvds> response. Note that the server asks for a decrease in the block size when acknowledging the first Block2. nit: From the trace, it looks like the server is the first one to use a 128-byte block size, and it does happen in an ack message, but that ack is not acking a block2 (though it contains one). (That ack message also happens to contain part of the response.) <pvds> Ai, that confuses a lot. Should read: Note that the client asks again for a decrease </pvds> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}--> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) The first line doesn't seem to match up -- doesn't the "N1" mean "fragment N1+1" but the descriptive text at the end say "frag# 1"? Or is this supposed to be 1:0/1/256? <pvds> Difficult to be terse and get it right: CSR (frag# n) means fragment n of the request Cert resp(frag# m) means fragment m of the response Like in figure 2, in figure 3, the line "... Immediate response when certificate is ready ...", Is added to separate the request sending from the response reception </pvds> Also, it surprised me somewhat that the client has to re-send the whole request (i.e., all fragments thereof) after the Max-Age interval when the server says it's ready, since that feels wasteful of bandwidth, but I assume that's just how CoAP works and not relevant for this document. <pvds>We did not see any other mechanism; but we are talking about many minutes, the relative bandwidth loss is not too high. This way, there is no need to keep much state, especially when many simultaneous requests are treated.</pvds> Section 5.8 In scenarios where it is desirable that the server generates the private key, server-side key generation should be used. Such nit: suggest s/should be used/is available/ to avoid the appearance of tautology. <pvds>done</pvds>
- [Ace] AD review of draft-ietf-ace-coap-est-12 Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Michael Richardson
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Michael Richardson
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Panos Kampanakis (pkampana)
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12 Peter van der Stok
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Panos Kampanakis (pkampana)
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-coap-est-12… Panos Kampanakis (pkampana)