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
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]
