Hi Timo, I think I have found the source of the misunderstanding, all this time I thought you were talking about flattening the JSON recipes but you might be referring to an expired pre-adoption draft?
The JSON objects holding selector, algorithm and signature value are from draft-clayton-dkim2-spec, the individual submission that preceded the working group document. Version -07 of that draft mapped various fields of Message-Instance and DKIM2-Signature into JSON, but the draft expired on 3 September. The WG document reversed that in its -00, whose changelog records removing JSON for hashes, signatures and SMTP parameters. In draft-ietf-dkim-dkim2-spec-06, section 8.9, the s= tag is a comma separated list of selector:algorithm:signature triples in plain ABNF. No JSON, no base64 wrapping of a structure, no parser beyond the tag scanner. Section 2 limits JSON to the Recipes in r= and nothing else. I mention this because clayton-08's signature JSON was in fact an array of positional three element arrays, so the design you are arguing against was already the one without named keys, and your proposal would move toward named objects rather than away from them. About the capability itself, -06 already supports what I think you may be after. Section 8.9 permits more than one signature at a single hop using different algorithms, plus one additional signature with the same algorithm and a different key length provided a different Selector is used. Both signatures sit in one DKIM2-Signature header field, sharing one i= and one d=, so there is no extra hop and no distortion of the Chain of Custody. Hybrid signing, classical alongside post-quantum, is expressible today without any JSON. Best, Mauro > On 16 Sep 2026, at 16:05, Timo Gerke <[email protected]> wrote: > > 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>_______________________________________________ > 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]
