Hi Paul,
Many thanks for the review comments. Please see my response below:
> 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
....." ? )
<M.S.> Agreed. Will change that. Will fix the "section 2.1 of [RFC..]" too.
> 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 ?
<M.S.> based on comments from Ben I changed it to SHOULD from MUST, here is
his comment
>>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
>>...".
However, you raised a valid point so I will change it to:
If the CoAP request is successful then the server MUST return a 2.XX
response code otherwise server MUST return an appropriate CoAP Client Error
4.xx or a Server Error 5.xx response code.
>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.
<M.S.> Agreed, I will change it to
If the server supports CMP Announcements messages, then it MUST
send an appropriate 2.xx success response code, otherwise it MUST
send a 4.xx
or 5.xx error response code.
>Now "can" is very strange here for not being a SHOULD or MAY or MUST
>
>
> can try after some time to register again
>
<M.S.> Agreed, Change it to "MAY 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" ?
<M.S.> Agreed, I will change it to
Alternatively, an EE MAY periodically poll for the current status of the CA
via the "PKI Information Request" message [Section 6.2 RFC 4210]. If
supported, EEs may also use "Support Messages" defined in section 4.3 of
the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] to get
information about the 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].
>
<M.S.> Agreed.
>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.
>
>
<M.S.> Agreed.
>
> 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.
>
<M.S.> Agreed.
>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.
>
<M.S.> Agreed.
>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.
<M.S.>
Here the intent is to warn the implementations to
>
>Section 5:
>
> This document requires a new entry to the CoAP
>
>s/requires/adds
>
> This document also requires
>
>s/requires/adds/
<M.S> Agreed.
>
> in the CMP protocol registry
>
>s/in/to
<M.S> Agreed.
>
>
> 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.
<M.S.>
This document references the cmp, in the Well-Known URIs IANA
registry. 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.
[Note RFC Editor: This document should be published together
or after the [I-D.ietf-lamps-cmp-updates] and
[I-D.ietf-lamps-lightweight-cmp-profile]
as it references IANA entries created by those Internet drafts.
>
>[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)
>
<M.S.> Agreed.
>
>NITS:
<M.S.> I will update the draft with suggested changes.
>
> 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
>
Regards,
Mohit
On Sun, Feb 26, 2023 at 5:49 PM Paul Wouters <paul.wout...@aiven.io> wrote:
> 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
