Subject: [core] WG Adoption Call for draft-mattsson-core-coap-attacks

From: Marco Tiloca <[email-masked]>
Date: Thu, 24 Feb 2022 17:21:29 +0100

Dear all,

This mail starts a 2 week Working Group Adoption Call for 
draft-mattsson-core-coap-attacks [1].

Please, provide your feedback by Wednesday, March 10.

Best,
Marco and Jaime

[1] https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 24 Feb 2022 22:48:43 +0100

Hi core,

in general I am in favor of the topic and I like most of the content and 
I think it should be a working group item to improve on in the WG context.

+1

Having said that, I think you are confusing freshness and recentness, 
fundamentally.

Freshness is not connected to recentness, but they are similar - and 
that is the tricky part. Something can be fresh after a huge amount of 
time according to a time-scale (not recent). Something can be stale 
after a tiny amount of time according to a time-scale (recent). 
Freshness is a quality of an assertion that expresses that the assertion 
still reflects the state of its subject, at the time of checking it. 
Freshness can be very tricky to check. Is that what you want? Probably 
not. My assumption is what you would want is a response with appropriate 
recentness (at least that is how I read your text).

Viele Grüße,

Henk

On 24.02.22 17:21, Marco Tiloca wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: <[email-masked]>
Date: Fri, 25 Feb 2022 07:23:34 +0000

Hi all,

I support adoption. 

It would helpful to explicit in Section 2.1 that this is about 7959, not the new block (to-be-RFC9177). Assessing the case of the new-block would be useful as well. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : core <[email-masked]> De la part de Marco Tiloca
> Envoyé : jeudi 24 février 2022 17:21
> À : [email-masked] WG ([email-masked]) <[email-masked]>
> Objet : [core] WG Adoption Call for draft-mattsson-core-coap-attacks
> 
> Dear all,
> 
> This mail starts a 2 week Working Group Adoption Call for draft-
> mattsson-core-coap-attacks [1].
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Fri, 25 Feb 2022 10:24:58 -0000

Hi All,

I likewise am in favor of this document, but would like to see a few changes / addition.

Med is actually referring to 2.4, but this made me realize there was a trap of seeing Block and hence thinking RFC7959 for 2.1 - "The Block Attack" which actually has no reference to CoAP blocks.  A better section title could be "The Blocking Attack" and s/Block Attack/Blocking Attack/ elsewhere.

For 2.4, "Fragment" in terms of CoAP blocks is not defined, and is not used in RFC7959 (RFC7959 refers to fragmentation issues outside of the CoAP layer), so is unclear that "fragment" is meant to be referring to a CoAP RFC7959 (or draft-ietf-core-new-block to-be-RFC9177) block.  

Thus, "2.4. The Request CoAP Block Rearrangement Attack" is a step in the right direction for me.  Then most of the usage of the word fragment needs to be replaced with block.

As a note for mitigating 2.4.1, to-be-RFC9177 requires the use of Request-Tag (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-4.3) and good use of tokens (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-6). 

The lost blocks recovery mechanisms in to-be-RFC9177 mitigate the risk of the wrong block being processed in a request by the server.

Again using Block-Wise transfers, there has not been consideration for a delay attack causing the server to send back the wrong data in a BLOCK2 response.  See https://github.com/core-wg/echo-request-tag/issues/77 .  If the attacker delays the first request (which triggers a BLOCK2 response), and then sends it just before/after the second request (also triggering a BLOCK2 response), the request for the next block for, say the second request, from the client may get back the block from either the first or second request.  This can only be mitigated using the Request-Tag on each request, even though BLOCK1 is not being used for the request.  I think this attack also needs to be included.

Regards

Jon

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 25 February 2022 07:24
> To: Marco Tiloca; [email-masked] WG ([email-masked])
> Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks
> 
> Hi all,
> 
> I support adoption.
> 
> It would helpful to explicit in Section 2.1 that this is about 7959, not the new
> block (to-be-RFC9177). Assessing the case of the new-block would be useful as
> well.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Achim Kraus <[email-masked]>
Date: Fri, 25 Feb 2022 17:22:11 +0100

Hi Jon,

I'm not sure about:

 > Again using Block-Wise transfers, there has not been consideration
for a delay attack causing the server to send back the wrong data in a
BLOCK2 response.  See
https://github.com/core-wg/echo-request-tag/issues/77 .  If the attacker
delays the first request (which triggers a BLOCK2 response), and then
sends it just before/after the second request (also triggering a BLOCK2
response), the request for the next block for, say the second request,
from the client may get back the block from either the first or second
request.  This can only be mitigated using the Request-Tag on each
request, even though BLOCK1 is not being used for the request.  I think
this attack also needs to be included.

Does this refer to RFC7959?

 > may get back the block from either the first or second request.

But the response will contain a token, which is used for
request-response matching. So, do you assume, that both request are
using the same token (maybe then more a unintended violation of the
token uniqness)?

best regards
Achim

---

From: <[email-masked]>
Date: Fri, 25 Feb 2022 20:32:05 -0000

Hi Achim,

draft-mattsson-core-coap-attacks has a focus on using Request-Tag to mitigate attacks.  Usage of ETag is not mandated in RFC7252 or RFC7959 as far as I can tell (but is in to-be-RFC9177), but using ETag with Block2 mitigates potential attack confusion. See attack below.

Otherwise, please see inline.

Regards

Jon

> From: Achim Kraus [mailto: [email-masked]]
> Sent: 25 February 2022 16:22
> To: [email-masked]
> Cc: [email-masked]; 'Marco Tiloca'; [email-masked]

Jon> Yes, as Block2s are being used as well as RFC9175
> using the same token (maybe then more a unintended violation of the

Jon> No.  I would be expecting the Token to be different in each request that asks for the next payload of the body.  Use of the same Token is not recommended as per RFC9175, but people do not realize that an empty token should not be used across multiple requests (another attack if "Foe" was removing tokens as the CoAP packets passed through...).

Jon> Client gets earlier value (ETag not used) against what it thought was the second request.

   Client   Foe   Server
      |      |      |
      +------X      |    POST "request" T:1 { "offset":0, "length":2000}
      |      |      |
      +------------->    POST "request" T:2 { "offset":4000, "length":2000}
      |      |      |
      |      @------>    POST "request" T:1 { "offset":0, "length":2000}
      |      |      |
      <-------------+    2.04 T:2 Block2:0/1/1024 { data containing 4000:1024 }
      |      |      |
      <-------------+    2.04 T:1 Block2:0/1/1024 { data containing 0:1024 }
      |      |      |
      +------------->    POST "request" T:3 Block2:0/_/1024
                         server - is this continuation of request using T:1 or T:2 ?
      |      |      |
      <-------------+    2.04 T:3 Block2:1/_/1024 { data containing 1024:2000 }
                         Was this the expected data ?
      |      |      |

This is fixed if Request differentiating ETag is used in the response. The client may not be able to get the missing secondary block from the alternative request, unless Request-Tag is used in the initial request (hence issue 77).

~Jon>

> > Med is actually referring to 2.4, but this made me realize there was a trap of
> seeing Block and hence thinking RFC7959 for 2.1 - "The Block Attack" which
> actually has no reference to CoAP blocks.  A better section title could be "The
> Blocking Attack" and s/Block Attack/Blocking Attack/ elsewhere.
> >
> > For 2.4, "Fragment" in terms of CoAP blocks is not defined, and is not used in
> RFC7959 (RFC7959 refers to fragmentation issues outside of the CoAP layer), so
> is unclear that "fragment" is meant to be referring to a CoAP RFC7959 (or
> draft-ietf-core-new-block to-be-RFC9177) block.
> >
> > Thus, "2.4. The Request CoAP Block Rearrangement Attack" is a step in the
> right direction for me.  Then most of the usage of the word fragment needs to
> be replaced with block.
> >
> > As a note for mitigating 2.4.1, to-be-RFC9177 requires the use of Request-Tag
> (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-4.3)
> and good use of tokens (https://datatracker.ietf.org/doc/html/draft-ietf-core-
> new-block#section-6).
> >
> > The lost blocks recovery mechanisms in to-be-RFC9177 mitigate the risk of
> the wrong block being processed in a request by the server.
> >
> > Again using Block-Wise transfers, there has not been consideration for a delay
> attack causing the server to send back the wrong data in a BLOCK2 response.
> See https://github.com/core-wg/echo-request-tag/issues/77 .  If the attacker
> delays the first request (which triggers a BLOCK2 response), and then sends it
> just before/after the second request (also triggering a BLOCK2 response), the
> request for the next block for, say the second request, from the client may get
> back the block from either the first or second request.  This can only be
> mitigated using the Request-Tag on each request, even though BLOCK1 is not
> being used for the request.  I think this attack also needs to be included.
> >
> > Regards
> >
> > Jon
> >
> >> If you have received this email in error, please notify the sender and delete
> this
> >> message and its attachments.