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 <[email protected]> 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 > <[email protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
