Hi David Many thanks for the comments, please see my response inline, I will wait for couple of more days for any new comments and will publish a new version of draft with the name change (cmpv2 -> cmp) and changes based on your feedback.
Regards, -Mohit On Thu, Apr 29, 2021 at 6:34 AM David von Oheimb <[email protected]> wrote: > > Hi Mohit, > > a couple of comments for the WGLC also from my side. > > Abstract: > > IMO it would be nice (but it's of course not strictly needed) to refer to the > Lightweight CMP profile already in the abstract, > maybe this way after the first sentence: > > It details the CoAP transfer option mentioned in the Lightweight CMP > Profile. > [M.S.]: Agreed. > Section 1: > > encryption of messages -> protection of messages (because authenticity is > the predominant requirement) > [M.S.] Agreed > between CAs -> between RAs (between CAs makes little > sense, but there may be more than one RA involved) > [M.S.] Cross certificate signing requires two CA's to communicate with each other (https://tools.ietf.org/html/rfc4210#section-6.6). > Section 2.6: > > the Block-Wise transfer [RFC7959] mode > MUST be used for the CMP Transactions over CoAP > > I do not have a strong opinion here, but I fear that strictly requiring > block-wise transfer may needlessly exclude simple implementations, > which may be sufficient in scenarios where the payloads are known to be > rather small. > Writing SHOULD or RECOMMENDED would state that implementors can deviate from > the recommendation, > but only if they are aware of the consequences and are willing to cope with > them. > So what you could do - if others agree - is to replace > > In order to avoid IP fragmentation of messages exchanged > between EEs and RAs or CAs, the Block-Wise transfer [RFC7959] mode > MUST be used for the CMP Transactions over CoAP. > > by a strengthened recommendation with a motivation/warning, e.g., > > Block-wise transfer [RFC7959] mode > SHOULD be used for the CMP Transactions over CoAP. > This is strongly recommended to avoid IP fragmentation of messages > and the block-wise option is a critical option as per RFC 7959. > [M.S.] In my opinion if we make this optional, then we will end up with implementations that will have to support both block-wise and non block-wise mode and may cause several interoperability issues. > Section 3: > > Nice to see that you streamlined the text regarding DTLS. > > Section 4: > > cross protocol proxy -> cross-protocol proxy [M.S.] Agreed. > > pre configured servers -> pre-configured servers > [M.S.] Agreed. > Section 5: > > In order to protect themselves against DDoS attacks, the > implementations SHOULD avoid sending or receiving very small packets > containing partial CMP PKIMessage data. > > Sounds good, but the point is not distributed DoS (only) but DoS in general, > so: DDoS -> DoS > and there is no real protection against DoS, just reduction of risks they > impose. > Moreover, the recipient has little influence on the size of packets. > I'd further suggest streamlining the sentence, arriving at, e.g.,: > [M.S.] DDos->Dos agreed > "In order to reduce the risks imposed by DoS attacks, > implementations SHOULD minimize fragmentation of messages, > i.e., avoid packets containing partial CMP PKIMessage data." > [M.S.] Agreed. > And better starting a new paragraph thereafter because using a CoAP-to-HTTP > proxy is a different topic. [M.S.] Agreed. > > Regards, > > David _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
