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

[Mohit Sahni <[e-mail]>]

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 <[e-mail]> 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
>
>