Did-core: What is storage amplification?

[clehner]

Security requirements requires that DID method specifications document forms of attack:

• A DID method specifications MUST follow all guidelines and normative language provided in RFC3552: Writing Security Considerations Sections for the DID operations defined in the DID method specification.
• The Security Considerations section MUST document the following forms of attack for the DID operations defined in the DID method specification: eavesdropping, replay, message insertion, deletion, modification, denial of service, storage or network amplification, and man-in-the-middle. Other known forms of attack SHOULD also be documented.

RFC 3552 mentions all these forms of attack, except for "storage or network amplification". I have heard of network amplification, and find it has occurred with many UDP-based protocols, but what is a storage amplification attack? Is it an attack on storage using network amplification? Or is this intended to refer to some other kind of attack involving storage, such as covert storage channels?

[kdenhartog]

A zip bomb is the first example that comes to mind for me on a storage amplification attack. Another viable one I could see is based on implementation design where a method chooses that referenced keys must keep a local cache of the keys available for the particular did rather than performing a lookup by reference on resolution. This would lead to the node storing large amounts of repetitive data in a way that amplifies the amount of data on the node without increasing the cost on the client relying upon the node.

Another example would be for a network that's storing underlying data on a blockchain, If I were to create a DID Document with 1GB of data inside it and all nodes must replicate the data then the attacker can effectively get every node to store 1GB of data eating up a considerable amount of storage in order for nodes to remain in sync. An example of this being performed against ethereum is documented here: https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/

[csuwildcat]

A zip bomb is the first example that comes to mind for me on a storage amplification attack. Another viable one I could see is based on implementation design where a method chooses that referenced keys must keep a local cache of the keys available for the particular did rather than performing a lookup by reference on resolution. This would lead to the node storing large amounts of repetitive data in a way that amplifies the amount of data on the node without increasing the cost on the client relying upon the node.

Another example would be for a network that's storing underlying data on a blockchain, If I were to create a DID Document with 1GB of data inside it and all nodes must replicate the data then the attacker can effectively get every node to store 1GB of data eating up a considerable amount of storage in order for nodes to remain in sync. An example of this being performed against ethereum is documented here: https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/

Yep, zip bombs are a good example - we have mitigations for this entire class of attack in Sidetree

[msporny]

@clehner -- do you have enough here to write an editorial PR to answer your question at this point?

[bumblefudge]

@chunningham @wyc either of you have language handy to help with this?

[csuwildcat]

Suggestion: Change the related text section zoom out and refocus on the broader class of "malicious resource consumption"(?) attacks, wherein an attacker constructs a file, operation, or code payload that is parsed/executed by a remote node in a distributed/decentralized system that causes those operators to consume resources in a manner that is beyond what is intended by the protocol/implementation. This could be via padding a ZIP file to cause memory consumption upon expansion, or crafting a smart contract with code that uses a massive amount of CPU beyond what the implementation intended.

[agropper]

Does this thread include spam mitigation tactics?
Who bears the cost of processing an unsolicited message?

On Tue, Apr 27, 2021 at 5:29 PM Daniel Buchner @.*>
wrote:

Suggestion: Change the related text section to include the broader class
of "malicious resource consumption"(?) attack, wherein an attacker
constructs a file, operation, or code payload that is parsed or executed by
a remote node in a distributed/decentralized system that causes those
operators to consume resources in a manner that is beyond what is intended
by the protocol/implementation. This could be via padding a ZIP file to
cause memory consumption upon expansion, or crafting a smart contract with
code that uses a massive amount of CPU that goes beyond whatever the
implementation intended.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/721#issuecomment-827976851, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABB4YIKW4W5WPAMJ6QHXI3TK43ERANCNFSM422KJ3AA
.

[iherman]

The issue was discussed in a meeting on 2021-05-04

• no resolutions were taken

View the transcript

7.5. What is storage amplification?

_See github issue #721._

Manu Sporny: There is enough there to write something. dbuchner wanted to expand it. Need to explain it; put in list of things to consider for DID method specification.

[msporny]

PR #730 has been raised to address this issue. This issue will be closed once PR #730 has been merged.

[msporny]

PR #730 has been merged, @clehner has explicitly confirmed that the PR addresses his concern, closing.