Hi Paul, I agreed to 2) and 3) for some reason change for 3) is missing in the draft. I will update the draft with resolution of 3). Item 1) has multiple sub items and out of those, for the last two open sub items, here are the snippet of my reply in my last email to Valery: ========================================================== > This text is insufficient, in my opinion. It is only concerned with > CoAP-to-HTTP proxy, while the resource exhausting attack can be mounted > against the CoAP server itself (in settings with no proxy). >
<M.S> Section 11 of rfc7252 covers all these scenarios with respect to various attacks on CoAP servers and how to mitigate them. I don't think it's useful to mention the same information here again since I have already added a reference to RFC7252 security considerations. ========================================================== > While definitely related, I do not think this text fully covers > consideration #2. The main idea is that without cryptographic > protection on transport level (DTLS) there is no protection of CoAP > metadata, so attackers may obtain quite a lot of useful information > (despite the CMP messages themselves are protected) and even > modify CoAP metadata. <M.S.> This is already mentioned in the section 3 for DTLS support: 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 <xref target="RFC9147"/> MAY be used providing a hop-by-hop security. ========================================================== I will update the draft with resolution of 3). Thanks Mohit On Fri, Jan 27, 2023 at 6:02 AM Paul Wouters <paul.wout...@aiven.io> wrote: > > On Fri, Jan 27, 2023 at 12:37 AM Mohit Sahni <mohit06...@gmail.com> wrote: > >> Hi Paul, >> I have updated the draft to resolve Vallery's comments. >> > > Thanks for the update. > > I see the secdir review of Valery shows 3 items: > https://datatracker.ietf.org/doc/review-ietf-ace-cmpv2-coap-transport-05-secdir-lc-smyslov-2022-10-18/ > It seems from the diff that you addressed 2) but not 1) and 3). Did you > dicsuss this with him and conclude this was not necessary ? > > Paul > > Thanks >> Mohit >> >> On Thu, Jan 26, 2023 at 9:30 PM <internet-dra...@ietf.org> wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Authentication and Authorization for >> Constrained Environments WG of the IETF. >> > >> > Title : CoAP Transfer for the Certificate Management >> Protocol >> > Authors : Mohit Sahni >> > Saurabh Tripathi >> > Filename : draft-ietf-ace-cmpv2-coap-transport-06.txt >> > Pages : 11 >> > Date : 2023-01-26 >> > >> > Abstract: >> > This document specifies the use of Constrained Application Protocol >> > (CoAP) as a transfer mechanism for the Certificate Management >> > Protocol (CMP). CMP defines the interaction between various PKI >> > entities for the purpose of certificate creation and management. >> > CoAP is an HTTP-like client-server protocol used by various >> > constrained devices in the IoT space. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/ >> > >> > There is also an htmlized version available at: >> > >> https://datatracker.ietf.org/doc/html/draft-ietf-ace-cmpv2-coap-transport-06 >> > >> > A diff from the previous version is available at: >> > >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-cmpv2-coap-transport-06 >> > >> > >> > Internet-Drafts are also available by rsync at rsync.ietf.org: >> :internet-drafts >> > >> > >> > _______________________________________________ >> > Ace mailing list >> > Ace@ietf.org >> > https://www.ietf.org/mailman/listinfo/ace >> >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
