Subject: [core] Denial of service for clients: draft-ietf-core-too-many-reqs-04

From: Mohit Sethi M <[email-masked]>
Date: Fri, 19 Oct 2018 05:44:40 +0000

Hi CoRE,

I quickly went through draft-ietf-core-too-many-reqs-04. First, could 
you add a reference for the Max-Age option (Section 5.10.5 of RFC 7252)?

I see that the security considerations section mentions that if this 
response code is used unprotected, a client would have to wait for an 
extended period of time.

Perhaps it could state more explicitly that without any security, an 
honest client can suffer from a denial of service attack where it is 
blocked from requesting a resource that it wishes to access. I looked at 
RFC 7252 and found that an attacker could potentially block a client 
from requesting resources for 136.1 years by specifying the maximum 
allowed Max-Age. This would be considered a major denial-of-service for 
honest clients.

Perhaps you would want to go further and say that this response code 
SHALL/SHOULD be authenticated and integrity protected?

--Mohit

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Oct 2018 07:57:02 +0200

> SHALL/SHOULD be authenticated and integrity protected?

I think any security considerations section could include a sentence that the receiver of a message should trust it only as far as the authentication/freshness for the message carries.  If the attacker can inject responses at will, the client already has a problem.
The sentence at the end of section 5 already elucidates the specific form of the problem that this response code adds to that.

More specifically, if a client sends a request in nosec mode, there is not really that much the server can do to reply with authentication.

Grüße, Carsten

---

From: Ari Keränen <[email-masked]>
Date: Sun, 21 Oct 2018 18:13:47 +0000

Thank you for the review comments Mohit & Carsten!

I have addressed your comments in the draft version in Github (and plan to submit new version tomorrow):
https://github.com/core-wg/too-many-reqs/pull/4/files

* There’s now reference to MaxAge
* Added a note that you can trust the response code only to extent you trust the underlying security mechanisms

Cheers,
Ari

> On 19 Oct 2018, at 8.57, Carsten Bormann <[email-masked]> wrote:
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core