Re: [Ace] draft-ietf-ace-cmpv2-coap-transport-00.txt - do not mention V" of CMP in the document

[Mohit Sahni <[e-mail]>]

Hi David,
Thanks for your comments, they are very helpful. I apologize, I
thought i have replied to you earlier but later found out that the
email was still my draft messages.  I have made changes to the
abstract section and other items that you pointed out in my draft.
Just want to make some clarifications in respect to a few of your
comments.

Comment:
> maybe weaken?:   mode MUST be used -> mode SHOULD be used
Response:
In my opinion, MUST makes more sense here because firstly this will
avoid IP fragmentation in some of the cases and secondly Block-Wise
option is a critical option as per RFC 7959 and making is SHOULD may
cause some interoperability issues.

Comment:
> To reduce the DoS risk in particular with the need to split larger messages into smaller chunks to re-assemble them later,
> it should be pretty helpful if both sides of the connection minimize the number and contents of CMP message fields as far as possible,
> for instance by leaving out unimportant optional fields, using short strings, preferring PBM-based protection, and generally (also for the certificates being managed) using ECC rather than RSA.
> I suggest placing some remark like this in sections 2.6 and/or 5.
Response:
Based on your and Hendrik's comments, I have added following statement
in the security considerations:
"In order to protect themselves against DDoS attacks, the
implementations SHOULD avoid sending or receiving very small packets
containing partial CMP PKIMessage data."

Thanks
Mohit

On Thu, Mar 11, 2021 at 9:55 AM David von Oheimb
<[e-mail]> wrote:
>
> P.S.
>
> One of the few major comments I gave below was pertaining to the security considerations.
> AFAICS the only security issue induced by using CoAP/UDP with CMP is the increased vulnerability to DoS attacks.
>
> To reduce the DoS risk in particular with the need to split larger messages into smaller chunks to re-assemble them later,
> it should be pretty helpful if both sides of the connection minimize the number and contents of CMP message fields as far as possible,
> for instance by leaving out unimportant optional fields, using short strings, preferring PBM-based protection, and generally (also for the certificates being managed) using ECC rather than RSA.
> I suggest placing some remark like this in sections 2.6 and/or 5.
>
> On 11.03.21 18:10, David von Oheimb wrote:
>
> Hi Mohit,
>
> thanks a lot for providing that draft. It looks very good already.
>
> Good point by Hendrik to replace "CMPv2" by "CMP" since the version really does not matter here.
>
> I'd suggest dropping the hyperlinked reference from the abstract and
> a couple of further adaptations to the abstract, such that it becomes
>
>    This document specifies use of the Constrained Application Protocol
>    (CoAP) for transferring Certificate Management Protocol (CMP) messages.
>    It details the respective option mentioned in the Lightweight CMP Profile.
>    CMP defines the interaction between various PKI entities for certificate
>    enrollment and management.  CoAP is an HTTP-like client-server protocol
>    for use in constrained devices in IoT space.
>
> Further mostly very minor improvement suggestions are given below.
>
> Cheers,
>     David
>
>
> Section 1:
>
> transport -> transfer (several times)
> encryption of messages -> protection of messages
> between CAs -> between RAs
>
> Section 2:
>
> PKIMesssage -> PKIMesssages
>
>
> I do not understand what you want so say here:
>
> An EE MUST verify the configured Root CA
> certificate against the Root CA certificate of the discovered entity
>
> Likely you meant:
>
> An EE MUST verify the certificate of the discovered entity
> against a configured trust anchor (Root CA certificate)
>
>
> The URI's for CoAP resources should start ->
> The only difference is that the URIs for CoAP resources MUST start
>
> should return a "2.05 Content" ->
> MUST return a "2.05 Content"
> (or are there other options in case of success?)
>
> application/pkixcmp -> "application/pkixcmp"
>
> for the possible changes -> for potential changes
>
> Block Wise -> Block-Wise (in title of 2.6)
> Block Wise -> block-wise (in body of 2.6)
>
> header body and optional fields ->
> header, body, protection, and extraCerts including many optional and potentially bulky fields
>
> outgoing interface -> interface
> (because this may also happen for responses)
>
> maybe leave out?   that are exchanged between EEs and RAs or CAs
>
> maybe weaken?:   mode MUST be used -> mode SHOULD be used
>
> then, it -> then it
>
> Proxy opens -> the proxy opens
>
> maybe leave out?   from EEs to RAs or from EEs to CAs
>
> Section 3:
>
> the encryption and authentication of the messages but in cases when ->
> protecting message contents, in case
>
> 7.1 and 7.2 -> 7.2 and 7.3
> (for draft 03 at least)
>
> overhead of using DTLS connection -> overhead of setting up DTLS connections
>
> Sections 4 and 5:
>
> CoAP to HTTP -> CoAP-to-HTTP
> (several times)
>
> significant changes -> changes
>
> Announcements Messages -> announcement messages
>
> MUST be positioned -> SHOULD be positioned
> (else the recommendation given next makes no sense)
>
> between CAs and RAs -> between RAs and CAs
>
> UDP based -> UDP-based
> (two times)
>
> CoAPs to HTTPS -> CoAPS-to-HTTPS
>
> HTTPS protocol, -> HTTPS.
>
> however client SHOULD be configured to trust the CA certificate used by proxy to sign the Man in the Middle (MITM) certificate for certificate chain validation ->
> The client SHOULD be configured with a trust anchor suitable for validating the DTLS server certificate used by the proxy
>
> I doubt if the paragraph
>
>    However, the CoAP protocol which
>    uses UDP as layer 4 transport is vulnerable to many issues due to the
>    connectionless characteristics of UDP itself.  The Security
>    considerations for CoAP protocol are mentioned in the [RFC7252].
>    Using a CoAP to HTTP proxy mitigates some of the risks as the
>    requests from the EE's can terminate inside the trusted network and
>    will not require the server to listen on a UDP port making it safe
>    from UDP based address spoofing, Denial of Service, and amplification
>    attacks due to the characteristics of UDP.
>
> makes sense because, as you wrote before, CMP is already self-contained in terms of security.
> Therefore I think it should be sufficient to say for instance:
>
> Therefore security issues of CoAP due to using UDP do not carry over to the CMP layer
> except for the vulnerability to Denial-of-Service attacks.
>
>
> Section 6:
>
> content-type application/pkixcmp -> content type "application/pkixcmp".
>
>
>
> On 10.03.21 19:44, Mohit Sahni wrote:
>
> Hi Hendrik
> Thanks for the update, I will make changes to remove the CMP version
> references from the document. I think we can exclude CMPv1 from the
> scope as it will obsolete soon.
>
> Thanks
> Mohit
>
> On Fri, Mar 5, 2021 at 9:36 AM Brockhaus, Hendrik
> <[e-mail]> wrote:
>
> Mohit
>
>
>
> We introduced V3 of CMP in draft-ietf-lamps-cmp-updates-08 Section 2.15. The version of CMP is not relevant to the CoAP transport, I guess. Therefore, I suggest to  remove references to the CMP version from your draft, especially from the title. If you want to exclude CMP V1 as specified in RFC 2510 from the scope of your draft, this is fine with me as well.
>
>
>
> Hendrik