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

[Benjamin Kaduk <[e-mail]>]

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