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]
