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

[Robert Wilton via Datatracker <[e-mail]>]

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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/



----------------------------------------------------------------------
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"