Hi Valery Apologies for not getting back on time, and a Happy New Year. Please see my response to your responses: > 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. > Using CoAP over DTLS is not specific to the CMP over CoAP, > It can be use with any protocol utilizing CoAP. You added > no additional requirements for using CoAP over DTLS that are specific to > CMP (except for recommendation to use long-lived connections). > For this reason I think that it is more natural to place > this text in Security Considerations (as in RFC 6712). <M.S.> Agreed, I will move the DTLS section in the security considerations. > My point was that CoAP is vulnerable *not only* "due to the connectionless > characteristics of UDP itself". There are a lot of different aspects that are > covered in details in the Security Considerations in RFC 7252. So I think you should either > explain why you think it is UDP that makes CoAP vulnerable or (better IMO) > delete this sentence as vague and just keep the next sentence referencing > Security Considerations of CoAP. <M.S.> Agreed, I will remove the statement "due to the connectionless characteristics of UDP itself" Please let me know if you agree to my responses to your comments. Regards, Mohit On Fri, Nov 11, 2022 at 12:31 AM Valery Smyslov <valery@xxxxxxxxxxx> wrote: > > Hi Mohit, > > I apologize for delayed response - IETF week is always a busy week. > > > Hi Valery > > Here is my response to your comments, please let me know if this > > resolves the comments. > > > > ==================================== > > > 1. I believe that the security considerations from RFC 6712 should be either > > > echoed in this document (where applicable), or at least be referenced. > > <M.S.> The HTTP and CoAP are different but similar protocols, I have > > covered applicable security considerations in this draft: > > > > Consideration #1 in the RFC 6712 is echoed in following paragraph: > > The proxy however may itself be vulnerable to resource-exhaustion > > attacks as it's required to buffer the CMP messages received over > > CoAP transport before sending it to the HTTP endpoint. This can be > > mitigated by using short timers for discarding the buffered messages > > and rate limiting clients based on the resource usage. > > 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). > > > Consideration #2 in the RFC 6712 is covered as > > > > 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 > > 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. > > > Consideration #3 in the RFC 6712 is not applicable to CoAP transport > > OK. > > > Consideration #4 in the RFC 6712 is covered as > > > > 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. > > OK. > > > And Consideration #5 is covered in the section 3 "Using CoAP over > > DTLS" of the draft. > > Yes. > > > ==================================== > > > > >I think that Section 3 (Using CoAP over DTLS) should be moved to the > > >Security Considerations section, or be referenced from there. > > > > Can you please provide a reasoning on why section 3 should be > > referenced in the Security Considerations section? > > Using CoAP over DTLS is not specific to the CMP over CoAP, > It can be use with any protocol utilizing CoAP. You added > no additional requirements for using CoAP over DTLS that are specific to > CMP (except for recommendation to use long-lived connections). > For this reason I think that it is more natural to place > this text in Security Considerations (as in RFC 6712). > > > Part of it is covered in > > > > ==================================== > > > The CoAP is vulnerable due to the connectionless characteristics of UDP > > > itself. > > > should either be expanded of what particular vulnerabilities are meant (because > > > not all CoAP vulnerabilities are concerned with using UDP) or deleted. > > > > I believe following statement in the security considerations covers this: > > > > The Security considerations for CoAP are mentioned in the [RFC7252]. > > My point was that CoAP is vulnerable *not only* "due to the connectionless > characteristics of UDP itself". There are a lot of different aspects that are > covered in details in the Security Considerations in RFC 7252. So I think you should either > explain why you think it is UDP that makes CoAP vulnerable or (better IMO) > delete this sentence as vague and just keep the next sentence referencing > Security Considerations of CoAP. > > Regards, > Valery. > > > Thanks > > Mohit > > > > On Tue, Oct 18, 2022 at 4:54 AM Valery Smyslov via Datatracker > > <noreply@xxxxxxxx> wrote: > > > > > > Reviewer: Valery Smyslov > > > Review result: Has Nits > > > > > > I have reviewed this document as part of the security directorate's ongoing > > > effort to review all IETF documents being processed by the IESG. These > > > comments were written primarily for the benefit of the security area directors. > > > Document editors and WG chairs should treat these comments just like any other > > > last call comments. > > > > > > This document defines the use of Constrained Application Protocol > > > (CoAP) as a transport for the Certificate Management Protocol (CMP). > > > > > > Nits: > > > 1. I believe that the security considerations from RFC 6712 should be either > > > echoed in this document (where applicable), or at least be referenced. > > > > > > 2. I think that Section 3 (Using CoAP over DTLS) should be moved to the > > > Security Considerations section, or be referenced from there. > > > > > > 3. Section 5. I think that the sentence > > > > > > The CoAP is vulnerable due to the connectionless characteristics of UDP > > > itself. > > > > > > should either be expanded of what particular vulnerabilities are meant (because > > > not all CoAP vulnerabilities are concerned with using UDP) or deleted. > > > > > > > > > > > > _______________________________________________ > > > Ace mailing list > > > Ace@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/ace > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
