Hi Timo, Both of your arguments hold only if implementers write a custom streaming parser against your schema. Neither holds for a standard JSON library, and I think that is the issue.
Regarding hash map allocation, an array of objects is still an array of objects. serde_json, Jackson, encoding/json and Python's json will allocate a map or dict per element, because each element has named fields. Under any off the shelf parser your design performs more hash map insertion than the schema you are proposing to replace, which inverts the argument. Zero hash map allocation would require an array of positional arrays rather than objects, and at that point the self-describing property of JSON is gone. Also, I did some research, and the hash flooding vector is largely historical for maintained libraries. Randomized hash seeding is available in Python, Ruby, Rust and the JVM ecosystem following the 2011/2012 disclosures, and Jackson ships input constraints by default. A gateway running a parser with deterministic unseeded hashing has a dependency problem, not a schema problem. Regarding nesting, strictly limits nesting to level 1 describes what conforming senders emit. It says nothing about what arrives. As I mentioned in my previous email, a standard parser handed 10,000 nested braces will recurse into them regardless of what the schema permits, because the attacker is not reading the schema. The immediate drop you want comes from a depth limit configured at the parser, and that limit works identically against a nested schema. If implementers use standard libraries, your array allocates more hash maps and handles recursion no differently, so it is worse on your own criterion. If implementers write custom streaming parsers for wire speed drops, they can enforce a depth cap against the current schema just as easily, so the array gains nothing. Schema shape does not determine parser architecture, and the defence has to sit at the parser either way. Separately, have you benchmarked any of this, or tested these vectors against actual JSON libraries? Taking Rust as the example, neither point survives contact with serde_json. Deserializing into a typed struct allocates no hash map whatever the shape of the document, because serde resolves field names through code generated at compile time rather than through a runtime map, so hash flooding has nothing to attack. And the recursion limit is not an optional hardening step, it is the default, capped at 128 levels unless an implementer explicitly disables it. A hostile document is rejected during the parse, at wire speed, without any change to the schema. I would be glad to look at numbers if you have them, but the claims as stated do not describe how the mainstream parsers actually behave. Best, Mauro > On 16 Sep 2026, at 14:41, Timo Gerke <[email protected]> wrote: > > Ciao Mauro, > Hi all, > > As I already wrote, flat JSON arrays provide a massive advantage > to CRITIS environments: predictable parsing time. > > 1. Nesting: Deeply nested objects force standard parsers into > recursive allocation. This is crucial with a real load in > productive, possibly CRITIS environments, provoking > unpredictable errors under a DDoS attack. A flattened > array strictly limits nesting to level 1 at the structural > layer, allowing immediate wire-speed drops. > > 2. Hash Flooding: Standard parsers allocate internal hash maps to > resolve name/value pairs, making them vulnerable to engineered > collision attacks. A flattened JSON array requires zero hash > map allocation. It is processed as a pure linear stream. > Algorithmic key-flooding becomes structure. > > Best regards, > Timo > > > It looks like Mauro De Gennaro aimed to say: >> Hi Timo, >> >>> A flattened JSON array forces strict sequential determinism. >>> It ensures that duplicate context tags cannot overwrite each >>> other or create ambiguous parsing paths. >>> >>> Regarding predictable parsing time: Sterile lab setups do not >>> simulate a CRITIS gateway under a DDoS attack. Deeply nested JSON >>> opens the door to algorithmic complexity exploits. An array >>> guarantees linear O(n) parsing time at wire speed. >>> >>> My idea of a flat array reduces the attack surface to the >>> smallest possible level. It provides security by design, rather >>> than security by policy. >> >> On flattening as a DoS mitigation: changing the schema does not change what >> arrives on the wire. An attacker sending a hostile value is not emitting >> schema-conformant JSON. They will send 10,000 levels of nesting whether the >> spec describes nested objects or a flat array. A verifier therefore has to >> bound depth and input length at the parser under either design, and since >> the mitigation is identical either way, flattening buys no additional >> resistance. >> >> Regarding linear time, a conforming JSON parser makes a single pass and >> consumes each token exactly once, regardless of shape. Nesting depth >> determines how much parser stack is live at a given moment, not how many >> times any byte is examined. Nested JSON is already O(n) in input length, so >> the guarantee you want from the array is one the current design has. JSON >> also cannot express the expansion attacks that motivate this worry in other >> formats, because it has no entity or anchor references; output size is >> bounded by input size. >> Also, about algorithmic complexity attacks specifically, in JSON these are >> normally hash flooding, many colliding keys within a single object degrading >> insertion. That depends on key count per object, not on depth, so flattening >> does not mitigate it. >> >> >> Best, >> Mauro >> >> >> >> _______________________________________________ >> Ietf-dkim mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > > Timo Gerke > Hamburg, Germany > > "If you think technology can solve your security > problems then you don't understand the problems > and you don't understand the technology." > -- Bruce > Schneier<OpenPGP_0x9F03DF9F597BF31E.asc>_______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
