Re: [core] I-D Action: draft-ietf-core-attacks-on-coap-01.txt

Hi John,
Hi List,

I appreciate the added statement about encryption in the abstract.
Does the

"Several of the discussed attacks can be mitigated with the solutions in
RFC 9175."

require the combination with encryption in order to mitigate the
attacks? I think so.

Overall, I'm wondering, if the preconditions of such attacks could be
documented clearer?

E.g. assuming an "on-path-attacker" RFC 9175 without encryption may be
in vain.

A couple of attacks assume, that tokens are reused frequently. In my
experience, that's not the case (except in cases, where someone stick to
(re-)use the empty token to save bandwidth, or reuse tokens for
testing/debugging). Different tokens and replay-windows are then
creating also protection in a couple of cases.

With a list of preconditions it would be easier to see,
if a system is affected by that attack or not.

You added "availability", but I miss the see an example, if there
is a specific risk using coap.

best regards
Achim

P.S.: about the "time shifting attacks" in general:
I'm not sure, if the core-wg did already consider to standardize some
aspects of "time"?
E.g. introduce coap-options to contain times for "now", "created", and
"last update" of the resources. I did recently a small experiment with
"now" and in my use-case that simplifies some cases.
I use a 0 to request times, and the millis since 1970-01-01 00:00:00
(java like :-) ) as values for the times. The devices starts requesting
the time from the server by sending "opt time: 0" and gets back the
server's time in the response also with "opt time: now in millis".
In follow up requests the device sends then the updated time in the
request "opt time: now" and the server only respond with a "time opt:"
if that time need to be adjusted. The requires some timers on the
device, but no RTC. If someone is interested, I may send a more
elaborated e-mail not to capture the topic of this one.

Am 10.11.22 um 12:04 schrieb John Mattsson:
> Hi,
>
> This update tries to address many but not all of the WGLC comments:
>
>   * “block attack” renamed “blocking attack”
>   * Added ”availability” to list of required properties
>   * Added that the freshness definition comes from RFC 9175
>   * Several changes to abstract and introduction based on Achim’s comment
>
> Left to do of WGLC comments:
>
>   * All the comments related to the Request Fragment Rearrangement Attack
>   * Maybe more changes based on Achim’s comment
>
> Cheers,
>
> John
>
> *From: *core <core-bounces@ietf.org> on behalf of
> internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Thursday, 10 November 2022 at 10:54
> *To: *i-d-announce@ietf.org <i-d-announce@ietf.org>
> *Cc: *core@ietf.org <core@ietf.org>
> *Subject: *[core] I-D Action: draft-ietf-core-attacks-on-coap-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Constrained RESTful Environments WG of
> the IETF.
>
>          Title           : Attacks on the Constrained Application
> Protocol (CoAP)
>          Authors         : John Preuß Mattsson
>                            John Fornehed
>                            Göran Selander
>                            Francesca Palombini
>                            Christian Amsüss
>    Filename        : draft-ietf-core-attacks-on-coap-01.txt
>    Pages           : 19
>    Date            : 2022-11-10
>
> Abstract:
>     Being able to securely read information from sensors, to securely
>     control actuators, and to not enable distributed denial-of-service
>     attacks are essential in a world of connected and networking things
>     interacting with the physical world.  Using a security protocol such
>     as DTLS, TLS, or OSCORE to protect CoAP is a requirement for secure
>     operation and protects against many attacks.  This document
>     summarizes a number of known attacks on CoAP deployments and show
>     that just using CoAP with a security protocol like DTLS, TLS, or
>     OSCORE is not enough for secure operation.  Several of the discussed
>     attacks can be mitigated with the solutions in RFC 9175.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-attacks-on-coap/
> <https://datatracker.ietf.org/doc/draft-ietf-core-attacks-on-coap/>
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-core-attacks-on-coap-01.html
> <https://www.ietf.org/archive/id/draft-ietf-core-attacks-on-coap-01.html>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-attacks-on-coap-01
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-core-attacks-on-coap-01>
>
>
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> <https://www.ietf.org/mailman/listinfo/core>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core