AD review: draft-ietf-ace-cmpv2-coap-transport-07
Please see below my AD review comments. I believe a revision of the document
is required before sending it to the IESG. The substantial comments are
mostly
about SHOULD vs MUST cases, but there is also a few large pieces of text,
mostly
in the Security Considerations section, that need to be reformulated for
clarity.
I've tried to propose text where I can.
I've also tried to fixup a few spelling and grammer issues.
Regards,
Paul
A CMP client SHOULD send each CoAP requests marked as a Confirmable
message Section 2.1 of [RFC7252].
When would one not use a Confirmable message ? eg why is this a SHOULD and
not a MUST ?
(also, the sentence doesn't make, did you mean to add "as per Section 2.1
....." ? )
If the CoAP request is successful then the server SHOULD return a
"2.05 Content" response code.
What else could be sent if the SHOULD is not followed? Eg why is this is a
SHOULD and not a MUST ?
If the CoAP request is not successful then an appropriate CoAP
Client Error 4.xx or a Server Error 5.xx response code MUST
be returned.
Especially seeing there is a MUST here.
This gets stranger even in this sentence, where it becomes very unclear:
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.
eg the 'otherwise' clause is not using a SHOULD or MUST, does it inherit the
one from the previous sentence? Also, why SHOULD and not MUST?
it can omit the Observe option
Now "can" is very strange here for not being a SHOULD or MAY or MUST
can try after some time to register again
Same here.
Alternatively, an EE MAY poll for the potential changes
What is meant with "potential changes" ?
(also the grammar of this sentence does not work)
to get information about the changes.
Also here, what "changes" ?
Section 4:
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 without cryptographic protections
for message confidentiality and integrity, do not carry over to
the CMP layer. The Security considerations for CoAP are mentioned
in the [RFC7252].
This is a very vague sentence that also does not read well. And I do not
understand the "carry over" parts. Perhaps something like:
All payloads 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].
Similarly the second point:
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.
Perhaps instead:
The CMP protocol does not provide confidentiality of the CMP
payloads.
If confidentiality is desired, CoAP over DTLS [RFC9147] can be used
to provide confidentiality for the CMP payloads, although it cannot
conceal that the CMP protocol is used within the DTLS layer.
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.
I think the reference to "as long as possible" is a bit strange. How about:
DTLS associations SHOULD be kept alive and re-used where possible
to amortise on the additional overhead of DTLS on constrained
devices.
The next bullet point just needs some grammar fixes:
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.
How about:
An EE might not witness all of the Announcement messages when using
the CoAP
Observe option [RFC7641], since the Observe option is a
"best-effort"
approach and the server might lose its state for subscribers to its
announcement messages. The EEs may use an alternate method described
in section 2.6 to obtain time critical changes such as CRL updates.
The next bullet I just do not understand:
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.
Please explain what is meant here and/or rephrase it.
Section 5:
This document requires a new entry to the CoAP
s/requires/adds
This document also requires
s/requires/adds/
in the CMP protocol registry
s/in/to
Description: The path to send a Get request
Should that be a "GET request" ?
This document references the cmp, in the Well-Known URIs IANA
registry. This document is expected to be published together
with [I-D.ietf-lamps-cmp-updates]. Please add a reference of
this document to the Well-Known URIs IANA registry for that entry
This document also refers the path segment "p" in the Certificate
Management Protocol (CMP) IANA registry. Please add a reference
of this document to the Certificate Management Protocol (CMP)
for that path segment.
Please seperate the addition instruction for IANA from the RFC Editor
instruction. Just state the additions as if the other documents were
already published, and then add a note using [Note RFC Editor: ...]
explaining this document should be published after the two referenced
ones.
[I-D.ietf-lamps-cmp-updates] and [I-D.ietf-lamps-lightweight-cmp-profile]
are listed as informative references, but these should be normative
references (as you point to sections in those documents for syntax)
NITS:
Here is the list of CMP announcement messages
Do not use "here". Maybe just: The list of CMP ....... are:
An EE MAY use CoAP Observe option
s/use/use the/
to get any announcement messages
s/any/all
If for some reason server cannot add
s/server/the server
A client on receiving
s/on receiving/that receives
allows the EE to receive
s/the EE/an EE
Since the CMP payload is same over CoAP and HTTP transfer mechanisms
Since the CMP payload is the same wether using CoAP or HTTP transfer
mechanisms
Some recommended mechanisms are as follows:
delete "as follows"
Since the Proxy may have access to the CMP-Level
s/may have/has
therefore proper role based access control should be in place.
s/therefore/, proper role based access controls should be deployed
Proxy can be
s/Proxy/Proxies
to protect them
s/to protect them/for protection
The proxy however may itself be vulnerable to resource-exhaustion
attacks
s/The proxy itself can also be attacked by resource-exhaustion attacks
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
