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 <ka...@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
