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 > On 24 Sep 2026, at 19:05, Timo Gerke <[email protected]> wrote: > > Hi Hannah, hi all, > > I hope, Hannah, I got it right now. > > This is a classical misunderstanding. MIME parsers are streaming > linear only. > > But JSON encapsulated in JSON is not linear. It requires building > a possibly complex DOM in memory. This can cause memory and/or > stack exhaustion. > > Furthermore, this structural vulnerability is not limited to > nesting depth: even long, flat JSON arrays break the streaming > paradigm completely, causing massive heap memory exhaustion > regardless of the nesting factor. > > If the specification permits undefined bounds here, a crafted > envelope triggers an immediate process collapse on kernel level > (OOM/SIGSEGV) before any application-layer check can even be > reached. > > Regards, > Timo > > > It looks like Hannah Stern aimed to say: >> Hi! >> >> On 9/23/26 21:06, Timo Gerke wrote: >>> I never said that JSON or REST APIs should be forbidden. I just >>> think, that global email transfer are the wrong use case for >>> them. >> >> Sorry for imprecise language. I meant: I don't think OWASP recommends >> against JSON use - not anyway, and especially not because using JSON on >> the network incurs the risks you quoted in your earlier post. >> >> So apparently OWASP in general sees it as possible to use JSON in ways >> compliant to those recommendations (as long as other applicable >> recommendations like input validation, unrestricted resource >> consumption... are followed). >> >> I'm not sure what distinguishes email from other protocols over the >> public network. >> >> Issues like arbitrarily deep nesting are something JSON has in common >> with other techniques that are used by the IETF in various places like >> MIME, XML, ASN.1. >> >>> It's not the task of the OWASP to forbid anything, but it is the >>> task of the IETF to define secure protocols. >> >> I don't see a contradiction. You _state_ that specifying JSON makes the >> protocol inherently insecure (or poses much higher risks to >> implementations than they have anyway). >> >> I'm not convinced. >> >> What I _am_ convinced of is my suggestion for the spec to forbid >> additional elements in the JSON in _all_ places (including top-level). >> >> What I'd also be more than ok with would be adding prose to Security >> Considerations that if one uses a generic JSON parser, that needs to >> fulfill the security requirements like in other settings where JSON is >> used in contact to potentially hostile adversaries. Parsing depth >> (CPU/memory) limiting, for example. >> >> Hannah. >> > > > 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]
