Last Call Review of draft-ietf-core-too-many-reqs-04
review-ietf-core-too-many-reqs-04-secdir-lc-migault-2018-10-07-00

Request Review of draft-ietf-core-too-many-reqs
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-12
Requested 2018-09-28
Other Reviews Tsvart Last Call review of -04 by Jana Iyengar (diff)
Genart Last Call review of -04 by Dan Romascanu (diff)
Review State Completed
Reviewer Daniel Migault
Review review-ietf-core-too-many-reqs-04-secdir-lc-migault-2018-10-07
Posted at https://mailarchive.ietf.org/arch/msg/secdir/WGmaTeh7V6iZhcDQi8iQbjli5tw
Reviewed rev. 04 (document currently at 06)
Review result Has Nits
Draft last updated 2018-10-07
Review completed: 2018-10-07

Review
review-ietf-core-too-many-reqs-04-secdir-lc-migault-2018-10-07

Hi, 

Reviewer: Daniel Migault
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. 

The document is clear and almost ready.  Most of my comments concerns the "Security Considerations". 

Yours, 
Daniel




4.  CoAP Client Behavior

   A client MUST NOT rely on a server being able to send the 4.29
   Response Code in an overload situation because an overloaded server
   may not be able to reply to all requests at all.

<mglt>

I believe the sentence may be rephrased. This is just a proposal.
OLD
   may not be able to reply to all requests at all.
NEW
   may not be able to reply (at all) to some requests. .

</mglt>

5.  Security Considerations

   Replying to CoAP requests with a Response Code consumes resources
   from a server.  For a server under attack it may be more appropriate
   to simply drop requests without responding.

<mglt>
The gain from the response with Too Many Requests Response Code is almost the current response and all *similar* requests from that client during Max Age. I suspect that is likely a gain except when there is no responses from the server and client is not expect to send a request before Max Age. Simply dropping the requests may add the retry traffic, though it depends on the application. That said your text is correct. I am wondering if it would be good to illustrate your purpose.  
</mglt>

   If a CoAP reply with the Too Many Requests Response Code is not
   authenticated and integrity protected, an attacker can attempt to



Keranen                 Expires January 25, 2019                [Page 3]

Internet-Draft  Too Many Requests Response Code for CoAP       July 2018


   spoof a reply and make the client wait for an extended period of time
   before trying again.

<mglt>
A similar attack may also consists in an attacker triggering multiple request or transactions with a spoofed IP so the server generates the reply to the legitimate IP. This could be used if an attacker cannot directly send the spoofed response to the legitimate client.

The response code provides an information about the state (overloaded) of the server which can be used to infer additional information. This could potentially be used by an active attacker among other to confirm an attack is efficient, that a server is receiving multiple packet at a given time which may be used to identify some traffic patterns, identifying a bug a version...  For a passive attacker, the response code may among other indicate an appropriated time to trigger a larger attack....

Because the code enable an attacker to gain some kind of control of the client, and reveals some information about the status of the server. I would suggest to mention that Too Many Response Code should not be considered outside unprotected channel. That is a server SHOULD NOT reply with a Too Many Requests Response Code unless the communication is encrypted. A client SHOULD ignore Too Many Response Code unless the communication is encrypted.     

The response seems to me small enough so reflection attacks may be out of scope.  
</mglt>