Ciao Mauro, Hi all, It seems there was some misunderstanding. I am not proposing an array of positional tuples, nor an array of objects with deep nested structures.
I am proposing a flattened JSON array containing flat,
single-level JSON objects representing distinct crypto contexts:
[
{"tag1": "value1", "tag2": "value2"},
{"tag3": "value3", "tag4": "value4"}
]
The less room for interpretation the spec has, the fewer faulty
implementations will exist.
With a flattened array of flat objects, the expected structural
nesting depth is strictly capped at level 2. A high-throughput
gateway under a real productive load can reject non-conforming
deeper structures at wire speed immediately upon inspecting the
token stream, preventing any deep allocation vectors and
eliminating undefined multi-parser anomalies (RFC 8259) by
design.
Best regards,
Timo
It looks like Mauro De Gennaro aimed to say:
> 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]
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
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
