Hi Robert, Many thanks for your review and comments. Please see my response below: > (1) p 2, sec 2.1. CoAP URI Format >Presumably the goal here is to keep the URLs reasonable short, is that worth stating at all? <M.S.>I left that out as it's implicit when using CoAP protocol. > (2) p 3, sec 2.3. CoAP Request Format >Noting that this is using RFC 2911 language, is this requirement specific to CMP over CoAP, or is this just restating CoAP behaviour. <M.S.> It's to avoid any ambiguity in what server should send and what client should expect. >(3) p 4, sec 2.4. CoAP Block-Wise Transfer Mode >It wasn't entirely obvious to me as to what entity "the server" is referring to in this paragraph. Perhaps worth being more specific? <M.S.> I will make it more clear that the server is referring to CA/RA in this case. >(4) p 4, sec 2.6. Announcement PKIMessage > I found this text very slightly confusing. E.g., the first part of the sentence is about supporting announcement messages, and the second part is about response codes. I presume that this is about replying to the register messages, but perhaps this could be made a bit clearer. <M.S.> The reference is in the previous paragraph where the path is mentioned """ The EE can send a GET request to the server's URI suffixed by "/ann". """ >(5) p 4, sec 2.6. Announcement PKIMessage >Would it be helpful to define or give guidance as what sort of period is recommended here (e.g., once per day, or once per year)? <M.S.> This is very implementation specific and how may resources server has and server may even have unexpected restarts. Therefore I did not provide a specific period here. >(6) p 5, sec 3. Proxy Support >Perhaps: "It is out of scope of this document to specify how a reverse ..." <M.S.> I will update the draft with your recommendation. > (8) p 5, sec 4. Security Considerations >Possibly a question for the SEC ADs, but would "without compromising the integrity of " be better than "without compromising the security" (given CMP does not provide confidentiality, as stated below)? <M.S.> This line has been rephrased quite a few times based on input from different reviewers. I did not receive a reply from SEC ADs on this comment. >(9) p 4, sec 2.6. Announcement PKIMessage >Suggest: "reason server" => "reason, the server" <M.S.> I will update the draft with your recommendation. >(10) p 5, sec 3. Proxy Support >Suggest: is same => is the same. I also suggest starting a new paragraph from "Since the". <M.S.> I will update the draft with your recommendation. >(11) p 6, sec 4. Security Considerations >Perhaps "avoid small datagrams" => "avoid sending small datagrams"? <M.S.> I will update the draft with your recommendation. >(12) p 6, sec 4. Security Considerations >Suggest "Proxy can" => "The proxy can" <M.S.> I will update the draft with your recommendation.
Thanks Mohit On Mon, May 8, 2023 at 12:02 PM Robert Wilton via Datatracker < nore...@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-ace-cmpv2-coap-transport-09: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_groups_iesg_statements_handling-2Dballot-2Dpositions_&d=DwICaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=RKLav3_i3qmtpZB0CSaJvGZjZt52RTzqEQ_xXH0RqWLzn2qGHhENuIm3IT3QAExo&s=rFCJTzmdbZK4jYo6WHcc1OlY2x6krfL1zk_cpjadY7U&e= > > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dace-2Dcmpv2-2Dcoap-2Dtransport_&d=DwICaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=RKLav3_i3qmtpZB0CSaJvGZjZt52RTzqEQ_xXH0RqWLzn2qGHhENuIm3IT3QAExo&s=hu4pAqCVPpm8TtCb8rJNVK1_-7MCiwwx4MXt-3WOixQ&e= > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document. > > I have some minor comments/suggestions that may improve this document: > > Minor level comments: > > (1) p 2, sec 2.1. CoAP URI Format > > coap://www.example.com/.well-known/cmp > coap://www.example.com/.well-known/cmp/<operation> > coap://www.example.com/.well-known/cmp/p/<name> > coap://www.example.com/.well-known/cmp/p/<name>/<operation> > > Presumably the goal here is to keep the URLs reasonable short, is that > worth > stating at all? > > (2) p 3, sec 2.3. CoAP Request Format > > If the CoAP request is > successful then the server MUST return a Success 2.xx response code > otherwise server MUST return an appropriate Client Error 4.xx or > Server Error 5.xx response code. > > Noting that this is using RFC 2911 language, is this requirement specific > to > CMP over CoAP, or is this just restating CoAP behaviour. > > (3) p 4, sec 2.4. CoAP Block-Wise Transfer Mode > > A CMP PKIMesssage consists of a header, body, protection, and > extraCerts structures which may contain many optional and potentially > large fields. Thus a CMP message can be much larger than the Maximum > Transmission Unit (MTU) of the outgoing interface of the device. The > EEs and RAs or CAs, MUST use the Block-Wise transfer mode [RFC7959] > to transfer such large messages instead of relying on IP > fragmentation. > If a CoAP-to-HTTP proxy is in the path between EEs and CA or EEs and > RA then, if the server supports, it MUST use the chunked transfer > encoding [RFC9112] to send data over the HTTP transport. The proxy > MUST try to reduce the number of packets sent by using an optimal > chunk length for the HTTP transport. > > It wasn't entirely obvious to me as to what entity "the server" is > referring to > in this paragraph. Perhaps worth being more specific? > > (4) p 4, sec 2.6. Announcement PKIMessage > > If the server supports CMP Announcements messages, then it MUST send > appropriate Success 2.xx response code, otherwise it MUST send an > appropriate Client Error 4.xx or Server Error 5.xx response code. > > I found this text very slightly confusing. E.g., the first part of the > sentence is about supporting announcement messages, and the second part is > about response codes. I presume that this is about replying to the > register > messages, but perhaps this could be made a bit clearer. > > (5) p 4, sec 2.6. Announcement PKIMessage > > A client on receiving a 2.xx success > response without the Observe option [RFC7641] MAY try after some time > to register again for announcements from the CMP server. Since > server can remove the EE from the list of observers for announcement > messages, an EE SHOULD periodically re-register itself for > announcement messages. > > Would it be helpful to define or give guidance as what sort of period is > recommended here (e.g., once per day, or once per year)? > > (6) p 5, sec 3. Proxy Support > > The CoAP-to-HTTP proxy can either be located closer to the EEs or > closer to the RA or CA. The proxy MAY support service discovery and > resource discovery as described in section 2.2. The CoAP-to-HTTP > proxy MUST function as a reverse proxy, only permitting connections > to a limited set of pre-configured servers. > > Given the RFC 2119 MUST, is there a definition or reference as to what is > meant > by reverse proxy? > > (7) p 5, sec 3. Proxy Support > > It is out of scope of > this document on how a reverse proxy can route CoAP client requests > to one of the configured servers. Some recommended mechanisms are as > follows: > > Perhaps: "It is out of scope of this document to specify how a reverse ..." > > (8) p 5, sec 4. Security Considerations > > * If PKIProtection is used, the PKIHeader and PKIBody of the CMP > protocol are cryptographically protected against malicious > modifications. As such, UDP can be used without compromising the > security of the CMP protocol. Security Considerations for CoAP > are defined in [RFC7252]. > > Possibly a question for the SEC ADs, but would "without compromising the > integrity of " be better than "without compromising the security" (given > CMP > does not provide confidentiality, as stated below)? > > Nit level comments: > > (9) p 4, sec 2.6. Announcement PKIMessage > > If > for some reason server cannot add the client to its list of observers > for the announcements, it can omit the Observe option [RFC7641] in > the response to the client. > > Suggest: "reason server" => "reason, the server" > > (10) p 5, sec 3. Proxy Support > > This section provides guidance on using a CoAP-to-HTTP proxy between > EEs and RAs or CAs in order to avoid changes to the existing PKI > implementation. Since the CMP payload is same over CoAP and HTTP > transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be > implemented based on section 10 of [RFC7252]. > > Suggest: is same => is the same. I also suggest starting a new paragraph > from > "Since the". > > (11) p 6, sec 4. Security Considerations > > * Implementations SHOULD use the available datagram size and avoid > small datagrams containing partial CMP PKIMessage data in order to > reduce memory usage for packet buffering. > > Perhaps "avoid small datagrams" => "avoid sending small datagrams"? > > (12) p 6, sec 4. Security Considerations > > * A CoAP-to-HTTP proxy can also protect the PKI entities by handling > UDP and CoAP messages. Proxy can mitigate attacks like denial of > service attacks, replay attacks and resource-exhaustion attacks by > enforcing basic checks like validating that the ASN.1 syntax is > compliant to CMP messages and validating the PKIMessage protection > before sending them to PKI entities. > > Suggest "Proxy can" => "The proxy can" > > > >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
