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

[Achim Kraus <[e-mail]>]

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

Am 25.02.22 um 11:24 schrieb [e-mail]:
> 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: [e-mail] [mailto:[e-mail]]
>> Sent: 25 February 2022 07:24
>> To: Marco Tiloca; [e-mail] WG ([e-mail])
>> 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
>>
>>> -----Message d'origine-----
>>> De : core <[e-mail]> De la part de Marco Tiloca
>>> Envoyé : jeudi 24 février 2022 17:21
>>> À : [e-mail] WG ([e-mail]) <[e-mail]>
>>> 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].
>>>
>>> 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: [phone]
>>> Isafjordsgatan 22 / Kistagången 16
>>> SE-164 40 Kista (Sweden)
>>
>>
>> ___________________________________________________________________
>> ______________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core