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