Re: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04

Hi Ben and Hello Paul,
I have published a new version for the draft that incorporates Ben's
Comments, I am sorry for the long delay that happened due to some
personal reasons. I want to thank Hendrik for his help and support in
resolving these comments.

In summary, I have accepted all the comments suggested by Ben except this one:

>    successful then the server MUST return a "2.05 Content" response
>    code.  [...]
>
> Perhaps I am reading too much into the analogy between HTTP and CoAP and
> thus to the applicability of draft-ietf-httpbis-bcp56bis (currently with the
> RFC Editor), but it doesn't seem terribly useful to name a specific response
> code here.  The standard CoAP semantics apply, and we could probably just
> say that "the paylaod of a successful response contains the DER-encoded
> ...".
The reason I am using a fixed response code "2.05 Content" in CoAP
transfer is to make is similar to the HTTP transfer (for the purposes
of backward compatibility)
(https://datatracker.ietf.org/doc/html/rfc6712#section-3.3) which
explicitly says that:

>The HTTP response status code in this case MUST be
>   200; other "Successful 2xx" codes MUST NOT be used for this purpose.

Please let me know if this is ok or not.

Here are the other main changes as per for comments: (I am skipping
the mention of Nits and Minor comments that I have resolved in the new
draft)
==============================================================
Section 2.1 Path URI:
OLD:
Optional path segments MAY
   be added after the registered application name (i.e. after "/.well-
   known/cmp") to provide distinction to support multiple PKI entities
   on the same endpoint.  A valid full operation path segment can look
   like this:

    coap://www.example.com/.well-known/cmp
    coap://www.example.com/.well-known/cmp/operationalLabel
    coap://www.example.com/.well-known/cmp/profileLabel
    coap://www.example.com/.well-known/cmp/profileLabel/operationalLabel

   Here operationalLabel may represent different CAs or Certificate
   profiles or supported End Entity types and profileLabel may represent
   different set of supported PKI operations on that particular path.

NEW:
Optional path segments MAY
   be added after the registered application name (i.e. after "/.well-
   known/cmp") to provide distinction.  The path segment 'p' followed by
   an arbitraryLabel <name> could for example support the
   differentiation of specific CAs or certificate profiles.  Further
   path segments, e.g., as specified in the Lightweight CMP Profile [I-
   D.ietf-lamps-lightweight-cmp-profile], could indicate PKI management
   operations using an operationLabel <operation>.  A valid full CMP URI
   can look like this:

       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>
==============================================================
> Is the last quoted sentence (fragment) an editing artifact or is there
> supposed to be more content there?
OLD:
Protocol (CMP).  purpose of certificate creation and management.
NEW:
   Protocol (CMP).  CMP defines the interaction between various PKI
   entities for the purpose of certificate creation and management.

==============================================================
> If I'm not mistaken, these ports 5683/5684 are the normal default ports for
> coap/coaps, as mandated by RFC 7252.  We don't need to restate that
> requirement using normative keywords, as the normative requirement is made
> in RFC 7252.  Instead (if anything), we should just provide a statement of
> fact, e.g., "the default port for coap: scheme URIs is 5683 and the default
> port for coaps: scheme URIs is 5684 [RFC7252]".  But really, we should be
> able to expect people to know to find the deafult port for a given URI
> scheme.

OLD:
If the port number is not specified in
   the authority, then port 5683 MUST be assumed for the "coap://"
   scheme and port 5684 MUST be assumed for the "coaps://" scheme.
NEW:
If the port number is not specified in the
   authority, then the default ports numbers MUST be assumed for the
   "coap:" and the "coaps:" scheme URIs.  The default port for coap:
   scheme URIs is 5683 and the default port for coaps: scheme URIs is
   5684 [RFC7252] .
==============================================================
>    When transferring CMP PKIMesssage over CoAP the media type
>    "application/pkixcmp" MUST be used.
>
> Do we want to say media type or content-format here?
OLD:
   When transferring CMP PKIMesssage over CoAP the media type
   "application/pkixcmp" MUST be used.
NEW:
   When transferring CMP PKIMesssage over CoAP the content-format
   "application/pkixcmp" MUST be used.
==============================================================
> Section 2.4 Comments:
OLD:
   A CMP PKIMesssage consists of a header, body, protection, and
   extraCerts structures.  These structures may contain many optional
   and potentially large fields, a CMP message can be much larger than
   the Maximum Transmission Unit (MTU) of the outgoing interface of the
   device.  In order to avoid IP fragmentation of messages exchanged
   between EEs and RAs or CAs, the Block-Wise transfer [RFC7959] mode
   MUST be used for the CMP Transactions over CoAP.  If a CoAP-to-HTTP
   proxy is in the path between EEs and CA or EEs and RA then it MUST
   receive the entire body from the client before sending the HTTP
   request to the server.  This will avoid unnecessary errors in case
   the entire content of the PKIMesssage is not received and the proxy
   opens a connection with the server.
NEW:
   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.
==============================================================
Section 2.6 Comments:
OLD:
   A CMP server may publish announcements, that can be event triggered
   or periodic, for the other PKI entities.  Here is the list of CMP
   announcement messages prefixed by their respective ASN.1 identifier
   (section 5.1.2 [RFC4210])

         [15] CA Key Update Announcement
         [16] Certificate Announcement
         [17] Revocation Announcement
         [18] CRL Announcement

   As there are no request messages specified for these announcement
   messages, an EE MAY use CoAP Observe option [RFC7641] in the Get
   request to the CMP server's URI followed by "/ann" to register itself
   for any Announcements messages.  If the server supports CMP
   Announcements messages, then it can respond with response code 2.03
   "Valid", otherwise with response code 4.04 "Not Found".  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 2.03
   response to the client.  A client on receiving 2.03 response without
   Observe option [RFC7641] can try after some time to register again
   for announcements from the CMP server.

   Alternatively an EE MAY poll for the potential changes via "PKI
   Information" request using "PKI General Message" defined in the
   PKIMessage [RFC4210] for various type of changes like CA key update
   or to get current CRL [RFC5280] to check revocation or using Support
   messages defined in section 5.4 of Lightweight CMP Profile
   [I-D.ietf-lamps-lightweight-cmp-profile] . This will help constrained
   devices that are acting as EEs conserve resources by eliminating the
   need to create an endpoint for receiving notifications from RA or CA.
   It will also simplify the implementation of CoAP-to-HTTP proxy.
NEW:
   A CMP server may publish announcements, that can be event triggered
   or periodic, for the other PKI entities.  Here is the list of CMP
   announcement messages prefixed by their respective ASN.1 identifier
   (section 5.1.2 [RFC4210])

         [15] CA Key Update Announcement
         [16] Certificate Announcement
         [17] Revocation Announcement
         [18] CRL Announcement

   An EE MAY use CoAP Observe option [RFC7641] to register itself to get
   any announcement messages from the RA or CA.  The EE can send a GET
   request to the server's URI suffixed by "/ann".  For example a path
   to register for announcement messages may look like this:

       coap://www.example.com/.well-known/cmp/ann
       coap://www.example.com/.well-known/cmp/p/<profileLabel>/ann

   If the server supports CMP Announcements messages, then it SHOULD
   send appropriate 2.xx success response code, otherwise a 4.xx or 5.xx
   error response code.  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.  A client on
   receiving a 2.xx success response without the Observe option
   [RFC7641] can 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.
==============================================================
Section 3:
> I'm not sure I understand what you mean by "end-to-end secrecy" for CoAP
> here -- DTLS is going to terminate at the closest entity that's named at the
> CoAP layer, which could include a CoAP or CoAP/HTTP proxy.  Full end-to-end
> secrecy between client and origin server would require an object sercurity
> mechanism like OSCORE.  DTLS would provide confidentiality protection
> against intermediate nodes at the IP layer, but that's only end-to-end in a
> certain sense.
OLD:
   Although CMP protocol does not depend upon the underlying transfer
   mechanism for protecting the messages but in cases when an end to end
   secrecy is desired for the CoAP, CoAP over DTLS [I-D.ietf-tls-dtls13]
   SHOULD be used.  Section 9.1 of [RFC7252] defines how to use DTLS
   [I-D.ietf-tls-dtls13] for securing the CoAP.  Once a DTLS
   [I-D.ietf-tls-dtls13] connection is established it SHOULD be used for
   as long as possible to avoid the frequent overhead of setting up a
   DTLS [I-D.ietf-tls-dtls13] connection for constrained devices.
NEW:
   Although the CMP protocol does not depend upon the underlying
   transfer mechanism for protecting the messages but in cases when
   confidentiality protection is desired, CoAP over DTLS [RFC9147] MAY
   be used providing a hop-by-hop security.  The use of DTLS can provide
   confidentiality protection of the CMP-level metadata, however it
   cannot obscure the fact that CMP is being used in the underlying
   layer.

   Section 9.1 of [RFC7252] defines how to use DTLS [RFC9147] for
   securing the CoAP.  Once a DTLS [RFC9147] association is established
   it SHOULD be used for as long as possible to avoid the frequent
   overhead of setting up a DTLS [RFC9147] association for constrained
   devices.
==============================================================
Section 4:
> Why does being closer to the RA or CA obviate the proxy from supporting
> service and resource discovery?  Won't there still be a need to expose the
> resources to the CoAP network regardless of how close it is to the EEs?
OLD:
   In case the proxy is deployed closer to the EEs then it may also
   support service discovery and resource discovery as described in
   section 2.2.  The CoAP-to-HTTP proxy MUST function as a reverse
NEW:
   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
==============================================================
Section 5:
> Should we say anything about how failing to receive announcement messages in
> a timely fashion can cause the EE to miss revocation events (and maybe other
> things as well)?  CoAP Observe notes that it is only a "best-effort"
> approach and the server could lose state about subscribed clients, which is
> probably worth re-emphasizing.

OLD:
NEW:
An EE may miss some of the Announcement messages when using CoAP
   Observe option [RFC7641] since Observe option is a "best-effort"
   approach and server can lose state about subscribers for announcement
   messages.  The EEs may use alternate method described in section 2.6
   to get time critical changes like CRL updates.
==============================================================
> We might also note that the use of DTLS can provide confidentiality
> protection for CMP-level metadata (though probably cannot obscure the fact
> that CMP is in use).
Updated in section 3
==============================================================
> I would also suggest making a statement about what security properties are
> required from a CoAP/HTTP proxy.  Since CMP itself provides end-to-end
> protections, I expect these requirements to be fairly weak (i.e., we don't
> need to trust the operator of it with any sensitive plaintexts), but it
> seems worth stating what considerations may arise.
OLD:
NEW:
   Since the Proxy may have access to the CMP-Level metadata and control
   over the flow of CMP messages therefore proper role based access
   control should be in place.  Proxy can be deployed at the edge of the
==============================================================
> Up in §2.4 we said ("MUST"!) to use block-wise transfer to avoid (IP)
> fragmentation.  Does this guidance apply to only IP fragmentation as well,
> or also to CoAP-layer "fragmentation" (i.e., block-wise transfer)?  The
> latter seems nearly impossible to achieve, given that the X.509 structures
> used by CMP are unchanged by this transport and are likely to be too large
> for a single datagram.
OLD:
   In order to to reduce the risks imposed by DoS attacks, the
   implementations SHOULD minimize fragmentation of messages, i.e. avoid
   small packets containing partial CMP PKIMessage data.
NEW:
   In order to to reduce the risks imposed by DoS attacks, the
   implementations SHOULD optimally use the available datagram size i.e.
   avoid small datagrams containing partial CMP PKIMessage data.
==============================================================
> What's the motivation behind just using a vague phrase "various attacks"
> instead of listing more details of known attacks (while still stating that
> the explicit listing is incomplete)?

OLD:
A CoAP-to-HTTP proxy can also protect the PKI entities from various
   attacks by enforcing basic checks and validating messages before
NEW:
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.

Regards,
Mohit

On Mon, Feb 14, 2022 at 11:25 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> Hi all,
>
> Jumping right in...
>
>
> I guess this is probably more of a comment on draft-ietf-lamps-cmp-updates,
> but since we are duplicating some of its content I will still call it out as
> a as a serious concern.  My concern relates to the usage of the "cmp"
> well-known URI -- we hvae some text in §2.1 that effectively says that a
> local site can just put more path segments under that path at its own
> discretion, and there's not even any restrictions made on the structucture
> of the additional path segments -- the next segment could be an operational
> label or a profile label, in the examples given.  This seems entirely at
> odds with the purpose of well-known URIs as per RFC 8615 -- they are to be
> URIs whose semantics are entirely specified by a protocol specification and
> are *not* subject to local operator control.  While it is possible for a
> specification to introduce additional structure under its registered
> well-known path, it's expected that the semantics of those subtrees are
> still specified by the protocol, and any extensions are to be managed by a
> (sub-)registry.  See, for example, §8.3.2 of RFC 8995, that establishes a
> sub-registry for the path components under /.well-known/brski .
>
> Any changes here will of course need to be synchronized with
> draft-ietf-lamps-cmp-updates, but I don't think this draft can go forward in
> its current form.
>
> Abstract
>
>    This document specifies the use of Constrained Application Protocol
>    (CoAP) as a transfer mechanism for the Certificate Management
>    Protocol (CMP).  purpose of certificate creation and management.
>
> Is the last quoted sentence (fragment) an editing artifact or is there
> supposed to be more content there?
>
>    CoAP is an HTTP like client-server protocol used by various
>    constrained devices in the IoT space.
>
> nit: hyphenate "HTTP-like"
>
> Section 1
>
>    messages.  The Constrained Application Protocol (CoAP) defined in
>    [RFC7252], [RFC7959] and [RFC8323] is a client-server protocol like
>    HTTP.  It is designed to be used by constrained devices over
>
> (editorial) I would suggest putting a paragraph break before talking about
> CoAP.
>
> Section 2.2
>
>                                   If the port number is not specified in
>    the authority, then port 5683 MUST be assumed for the "coap://"
>    scheme and port 5684 MUST be assumed for the "coaps://" scheme.
>
> If I'm not mistaken, these ports 5683/5684 are the normal default ports for
> coap/coaps, as mandated by RFC 7252.  We don't need to restate that
> requirement using normative keywords, as the normative requirement is made
> in RFC 7252.  Instead (if anything), we should just provide a statement of
> fact, e.g., "the default port for coap: scheme URIs is 5683 and the default
> port for coaps: scheme URIs is 5684 [RFC7252]".  But really, we should be
> able to expect people to know to find the deafult port for a given URI
> scheme.
>
> Section 2.3
>
>    CoAP POST request.  A CMP client SHOULD send CoAP requests marked as
>    Confirmable message ([RFC7252] section 2.1).  If the CoAP request is
>
> nit: singular/plural mismatch "message"/"requests".  Since we use the
> singular in the next sentence, going to singular here is probably best,
> e.g., "SHOULD send each CoAP request marked as a Confirmable message".
>
>    successful then the server MUST return a "2.05 Content" response
>    code.  [...]
>
> Perhaps I am reading too much into the analogy between HTTP and CoAP and
> thus to the applicability of draft-ietf-httpbis-bcp56bis (currently with the
> RFC Editor), but it doesn't seem terribly useful to name a specific response
> code here.  The standard CoAP semantics apply, and we could probably just
> say that "the paylaod of a successful response contains the DER-encoded
> ...".
>
>    When transferring CMP PKIMesssage over CoAP the media type
>    "application/pkixcmp" MUST be used.
>
> Do we want to say media type or content-format here?
>
> Section 2.4
>
>                            These structures may contain many optional
>    and potentially large fields, a CMP message can be much larger than
>    the Maximum Transmission Unit (MTU) of the outgoing interface of the
>    device.  [...]
>
> nit: comma splice
>
>    MUST be used for the CMP Transactions over CoAP.  If a CoAP-to-HTTP
>    proxy is in the path between EEs and CA or EEs and RA then it MUST
>    receive the entire body from the client before sending the HTTP
>    request to the server.  [...]
>
> It will be interesting to see what the ART and transport reviewers think of
> this guidance.  It seems like it is technically possible for the proxy to
> use a chunked encoding and stream the message without buffering, and it's
> not immediately clear to me that the cost of having to buffer chunks for
> reassembly outweights the cost of maintaining an HTTP connection in the
> current threat model.
>
> Also, nit: I would suggest using "EE" singular in both instances.
>
>                            This will avoid unnecessary errors in case
>    the entire content of the PKIMesssage is not received and the proxy
>    opens a connection with the server.
>
> I'm not sure I understand where these errors are such that they would be
> "unnecessary".  The client will certainly see an error condition even if not
> an error CoAP response, and the proxy will see an error condition of an
> incomplete request.  So I guess that would just leave the CA or RA as being
> protected from an error condition, but I don't really see why they need to
> be protected from them.  Isn't the occasional incomplete request just part
> of normal operation on best-effort networks?
>
> Section 2.6
>
>    As there are no request messages specified for these announcement
>    messages, an EE MAY use CoAP Observe option [RFC7641] in the Get
>    request to the CMP server's URI followed by "/ann" to register itself
>    for any Announcements messages.  [...]
>
> This is a pretty awkward sentence construction; I assume because it tries to
> allow for the flexibility in use of /.well-known/cmp/ that I complained
> about earlier.  Just saying that you can use Observe with a Get request to
> the /.well-known/cmp/ann resource is much simpler to state.
>
>                                     If the server supports CMP
>    Announcements messages, then it can respond with response code 2.03
>    "Valid", otherwise with response code 4.04 "Not Found".  [...]
>
> This reads a lot like we're trying to say that 2.03 and 4.04 are the only
> options, which BCP 56 (bis) says is an anti-pattern.
>
>                                                             If for some
>    reason server cannot add the client to its list of observers for the
>
> nit: "the server"
>
>    announcements, it can omit the Observe option [RFC7641] in the 2.03
>    response to the client.  A client on receiving 2.03 response without
>
> nit: "a 2.03 response"
>
>    Observe option [RFC7641] can try after some time to register again
>    for announcements from the CMP server.
>
> nit: "the Observe option"
>
>    Alternatively an EE MAY poll for the potential changes via "PKI
>
> nit: comma after "alternatively"
>
>    Information" request using "PKI General Message" defined in the
>    PKIMessage [RFC4210] for various type of changes like CA key update
>
> "PKI General Message" is a "PKIBody" type conveyed within the PKIMessage.
> Is it more clear to say something like '''using the "PKI General Message"
> choice for the PKIBody of the PKIMessage [RFC4210]'''?
>
> (editorial) I'd also suggest ending the sentence there, and starting a new
> sentence to list the common types of changes that would be polled for,
> perhaps as "This procedure allows the EE to receive various types of
> changes, like ..."
>
>    or to get current CRL [RFC5280] to check revocation or using Support
>    messages defined in section 5.4 of Lightweight CMP Profile
>    [I-D.ietf-lamps-lightweight-cmp-profile] .  [...]
>
> The Support messages seem to be in §4.3 of the lightweight profile now (not
> 5.4).
>
> Also (editorial), the list structure here seems hard to follow ("like <A> or
> <B> to <X> to <Y> or using <C>".  There are no list separators (e.g.,
> commas), and there is not clear parallelism between the structure of each
> list item (e.g., the last one is just "using Support messages" but the
> lead-in to the list is "various types of changes like" -- "combining those
> to "various types of changes like using Support messages" doesn't make a
> coherent clause ... so it's unclear if it's supposed to be part of the same
> list or not).
>
>    It will also simplify the implementation of CoAP-to-HTTP proxy.
>
> nit: singular/plural mismatch (the singular would need an article, for "a
> CoAP-to-HTTP proxy").
>
> Section 3
>
>    Although CMP protocol does not depend upon the underlying transfer
>    mechanism for protecting the messages but in cases when an end to end
>    secrecy is desired for the CoAP, CoAP over DTLS [I-D.ietf-tls-dtls13]
>    SHOULD be used.  [...]
>
> I'm not sure I understand what you mean by "end-to-end secrecy" for CoAP
> here -- DTLS is going to terminate at the closest entity that's named at the
> CoAP layer, which could include a CoAP or CoAP/HTTP proxy.  Full end-to-end
> secrecy between client and origin server would require an object sercurity
> mechanism like OSCORE.  DTLS would provide confidentiality protection
> against intermediate nodes at the IP layer, but that's only end-to-end in a
> certain sense.
>
> Also, nits: "end-to-end" is hyphenated as an adjective, "the CMP protocol",
> and s/ but/,/
>
>                     Section 9.1 of [RFC7252] defines how to use DTLS
>    [I-D.ietf-tls-dtls13] for securing the CoAP.  Once a DTLS
>    [I-D.ietf-tls-dtls13] connection is established it SHOULD be used for
>    as long as possible to avoid the frequent overhead of setting up a
>    DTLS [I-D.ietf-tls-dtls13] connection for constrained devices.
>
> nit: for DTLS we typically talk about an "association" rather than a
> "connection" (though the latest DTLS 1.3 draft does allow "connection" as a
> synonym for "association").
>
> Section 4
>
>    In case the proxy is deployed closer to the EEs then it may also
>    support service discovery and resource discovery as described in
>    section 2.2.  [...]
>
> Why does being closer to the RA or CA obviate the proxy from supporting
> service and resource discovery?  Won't there still be a need to expose the
> resources to the CoAP network regardless of how close it is to the EEs?
>
>    o  Use separate hostnames for each of the configured servers and then
>       use Server Name Indication ( [RFC8446] ) in case of "coaps://"
>       scheme for routing CoAP requests.
>
> RFC 6066 is probably a better reference for SNI than RFC 8446.
> Also, there still needs to be Uri-Host even when SNI is used, and the proxy
> needs to enforce that the two values match, in order to protect against
> request-smuggling attacks.
>
> Section 5
>
> Should we say anything about how failing to receive announcement messages in
> a timely fashion can cause the EE to miss revocation events (and maybe other
> things as well)?  CoAP Observe notes that it is only a "best-effort"
> approach and the server could lose state about subscribed clients, which is
> probably worth re-emphasizing.
>
> We might also note that the use of DTLS can provide confidentiality
> protection for CMP-level metadata (though probably cannot obscure the fact
> that CMP is in use).
>
> I would also suggest making a statement about what security properties are
> required from a CoAP/HTTP proxy.  Since CMP itself provides end-to-end
> protections, I expect these requirements to be fairly weak (i.e., we don't
> need to trust the operator of it with any sensitive plaintexts), but it
> seems worth stating what considerations may arise.
>
>    The CMP protocol depends upon various mechanisms in the protocol
>    itself for making the transactions secure therefore security issues
>    of CoAP due to using UDP do not carry over to the CMP layer.  [...]
>
> I think what we're trying to emphasize here is "using UDP without
> cryptographic protections for message confidentiality and integrity", since
> we go on to talk about how the connectionless nature of UDP remains an
> issue.
>
> Also, nit: comma before "therefore".
>
>    In order to to reduce the risks imposed by DoS attacks, the
>    implementations SHOULD minimize fragmentation of messages, i.e. avoid
>    small packets containing partial CMP PKIMessage data.
>
> Up in §2.4 we said ("MUST"!) to use block-wise transfer to avoid (IP)
> fragmentation.  Does this guidance apply to only IP fragmentation as well,
> or also to CoAP-layer "fragmentation" (i.e., block-wise transfer)?  The
> latter seems nearly impossible to achieve, given that the X.509 structures
> used by CMP are unchanged by this transport and are likely to be too large
> for a single datagram.
>
>    A CoAP-to-HTTP proxy can also protect the PKI entities from various
>    attacks by enforcing basic checks and validating messages before
>    sending them to PKI entities.  [...]
>
> What's the motivation behind just using a vague phrase "various attacks"
> instead of listing more details of known attacks (while still stating that
> the explicit listing is incomplete)?
>
> Also, we should note that putting the proxy in this position causes the
> proxy itself to be at risk of attack.  (In particular, our requirement for
> CoAP-to-HTTP proxies to buffer CoAP requests before initiating the outbound
> HTTP request subjects them to a resource-exhaustion attack.)
>
> Section 8.1
>
>    [RFC6712]  Kause, T. and M. Peylo, "Internet X.509 Public Key
>
> The RFC Editor will surely fix this, but it's quite unusual to mix "Last,
> FI" and "FI. Last" format for names in the same reference.
>
> Section 8.2
>
> I think DTLS 1.3 needs to be a normative reference based on how we give
> SHOULD-level guidance to use it.  (I don't think we're specifically tied to
> 1.3, though, and if for some reason DTLS 1.3 still hasn't been published by
> the time this document is ready, we could swap it out for DTLS 1.2.)
>
> Section 8.3
>
> The two URIs [1] and [2] seem to be identical; are they both needed?
>
>
> Thanks,
>
> Ben
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace