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

[Mohit Sahni <[e-mail]>]

Hi Ben,
Many thanks for your comments. I will review them and make the changes
accordingly.

Regards,
Mohit

On Mon, Feb 14, 2022 at 11:24 AM Benjamin Kaduk <[e-mail]> 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
>