Hi Mauro, You cannot securely implement an insecure specification.
Your reference to yyjson's linear scans confirms a textbook
O(n^2) algorithmic complexity DoS vector. Your reference to
simdjson's 1024 nesting depth completely validates Hannah's
industrial veto ("That's not nice, that's DoS.").
I will not engage in further discussions on this matter until an
official SECDIR and TSVART Early Review of spec-06 is available.
Regards,
Timo
It looks like Mauro De Gennaro aimed to say:
> Hi Timo,
>
> C/C++ email infrastructure isn't actually an obstacle to a resilient JSON
> implementation, it's solved territory:
>
> - yyjson is a two-file ANSI C library with zero dependencies, so it vendors
> into a C mail server as easily as any existing library there. The maintainer
> reports that it parses at about 1.7 to 1.8 GB/s (comparable to serde_json) on
> their cross-platform benchmarks (AWS EC2, AMD EPYC 7R32) .
>
> - simdjson is C++ but SIMD-accelerated and used in production by Node.js and
> others. In the same benchmark set it parses at about 1.5 GB/s on x86.
>
> And going back to your security concerns:
>
> - Nesting/stack-overflow DoS: yyjson's parser is iterative, not recursive, so
> it doesn't consume a native stack frame per nesting level, meaning deeply
> nested input can't overflow the stack. simdjson's DOM API caps nesting depth
> at 1024 by default and rejects anything deeper before it becomes a problem.
> Neither has the recursive-descent-by-default weakness.
>
> - Hash-collision DoS: neither library uses a hash table for object keys at
> all. yyjson stores members in a linked structure and does linear key lookup,
> and simdjson does a forward scan. There's no hash function for an attacker to
> target, so classic algorithmic-complexity/collision attacks don't apply.
>
> Both libraries are also fuzzed continuously (yyjson through its own CI,
> simdjson through OSS-Fuzz).
>
> I believe these facts settle the performance, nesting, and hash-collision
> concerns. At this point the burden of proof is on the other side, if you
> believe yyjson or simdjson can still be broken this way, the constructive
> next step is a proof-of-concept that demonstrates it, not a restatement of
> the concern.
>
>
> Best,
> Mauro
>
>
>> On 25 Sep 2026, at 15:26, Timo Gerke <[email protected]> wrote:
>>
>> Hi Mauro,
>>
>> But you know that about 90% of the worldwide email infrastructure
>> (sendmail, exim, postfix, and others) runs C on C++ based?
>>
>> Rust is only a side-note here.
>>
>> Regards,
>> Timo
>>
>> It looks like Mauro De Gennaro aimed to say:
>>> Hi Timo,
>>>
>>> I don’t do C anymore but here’s running Rust code of a full DKIM2
>>> implementation. Please do try to break it:
>>>
>>> mail-auth.png
>>> mail-auth/src/dkim2/mod.rs <http://mod.rs/> at main ·
>>> stalwartlabs/mail-auth <https://github.com/
>>> stalwartlabs/mail-auth/blob/main/src/dkim2/mod.rs <http://mod.rs/>>
>>> github.com <http://github.com/>
>>> <https://github.com/stalwartlabs/mail-auth/blob/main/src/dkim2/mod.rs>
>>>
>>> <https://github.com/stalwartlabs/mail-auth/blob/main/src/dkim2/mod.rs>
>>>
>>>
>>> Best,
>>> Mauro
>>>
>>> PS: https://xkcd.com/386/ <https://xkcd.com/386/>
>>>
>>>
>>>
>>>> On 24 Sep 2026, at 8:43 pm, Timo Gerke <[email protected]> wrote:
>>>>
>>>> Hi Mauro,
>>>> hi all,
>>>>
>>>> Yes Mauro, Streaming JSON would be possible, if it were a stream,
>>>> but it is encapsulated. When I hear SAX, I need to think about
>>>> music.
>>>>
>>>> BTW: Hannah also said "That's not nice, that's DoS. [...] Change
>>>> the spec to forbid additional items in the top-level JSON
>>>> Object. ", think about it.
>>>>
>>>> Mauro, if you think, that the actual design has no flaws,
>>>> provide running C code.
>>>>
>>>> Best,
>>>> Timo
>>>>
>>>> It looks like Mauro De Gennaro aimed to say:
>>>>> Hi Timo,
>>>>>
>>>>> Every conclusion in your message rests on assumptions about how a
>>>>> particular
>>>>> parser happens to be implemented.
>>>>>
>>>>> MIME is not linear by nature. It is a nested format: multipart containers
>>>>> can
>>>>> hold further multipart containers, and message/rfc822 parts can embed
>>>>> entire
>>>>> messages. A parser that recurses on that structure can be driven to stack
>>>>> exhaustion by a deeply nested message, and this has happened in real
>>>>> products. "Streaming and linear" describes a well-written MIME parser,
>>>>> not
>>>>> MIME itself.
>>>>>
>>>>> The same reasoning applies to JSON. JSON encapsulated in JSON does not
>>>>> require building a DOM. Streaming, event-based parsers have existed for
>>>>> many
>>>>> years and process input incrementally with bounded memory, including for
>>>>> long
>>>>> flat arrays. Whether an implementation builds a tree, recurses, or
>>>>> streams is
>>>>> a design decision by the library author, not a property of the format.
>>>>>
>>>>> The picture you describe is also outdated and does not match how modern
>>>>> libraries are written. Current parsers commonly enforce configurable
>>>>> limits
>>>>> on nesting depth, input size, and allocation, and they fail cleanly when
>>>>> those limits are hit. A crafted envelope causing an immediate process
>>>>> collapse describes a naive or unmaintained implementation, not the state
>>>>> of
>>>>> the art.
>>>>>
>>>>> The only vulnerability in this scenario is the use of a flawed library,
>>>>> and a
>>>>> specification cannot repair a flawed library. An implementer who picks a
>>>>> parser that cannot safely handle untrusted input will have the same
>>>>> problem
>>>>> with MIME, JSON, or any other format. I would ask that we not present
>>>>> this as
>>>>> a structural weakness of the DKIM2 design, because the argument does not
>>>>> hold up.
>>>>>
>>>>>
>>>>> Best,
>>>>> Mauro
>>>>>
>>>>
>>>>
>>>> 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] <mailto:[email protected]>
>>> To unsubscribe send an email to [email protected]
>>> <mailto:[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] <mailto:[email protected]>
>> To unsubscribe send an email to [email protected]
>> <mailto:[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]
