Re: [Ace] Robert Wilton's No Objection on draft-ietf-ace-cmpv2-coap-transport-09: (with COMMENT)

[Mohit Sahni <[e-mail]>]

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 <
[e-mail]> 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"
>
>
>
>