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

[Mohit Sahni <[e-mail]>]

Hi Paul,
Just noticed an incomplete response for this comment, responding again to
it.

>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.>The intent here is to instruct clients to send CMP messages in as few
packets as possible. Fragmentation of CMP messages may cause the server to
buffer packets which will consume resources on the server. With clients
instructed to send CMP messages in as few packets as possible, servers can
choose to ignore fragmented CMP messages to mitigate such DOS attacks.

-Mohit

On Fri, Mar 3, 2023 at 1:36 PM Mohit Sahni <[e-mail]>
wrote:

> 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
>>
>>