Hi Taavi, As a developer, you should know that undefined behavior is the worst case. An undefined behavior by specification is far worse.
Equating "undefined specification behavior" with architectural safety violates the core foundations of protocol design. Parsing differentials between inbound gateways and downstream systems (RFC 8259, Section 4) directly break cryptographic invariance by definition. If a security specification relies on downstream implementations guessing semantics of undefined structural inputs, the protocol layer itself is inherently vulnerable. A protocol specification is not a "suggestion" for error handling it is a strict mathematical boundary enforced on the wire to prevent algorithmic complexity DoS exploits prior to state execution. Best, Timo It looks like Taavi Eomäe aimed to say: > Hi, > > On 22.09.2026 14:18, Timo Gerke wrote: >> When a core protocol >> specification relies on a syntax where object behavior is >> explicitly declared as "undefined", it creates an architectural >> vulnerability. > > You haven't really properly proven how "undefined" means "vulnerable". > Mauro on the other hand described in depth how for a JSON parser neither > structure should or is an issue. > > >> A flattened object-array layout or a deterministic tag-value >> mechanism enforces strict linear O(n) parsing constraints >> directly on the protocol layer. This completely eliminates >> algorithmic complexity DoS and parsing differentials by design. > > It does not enforce it. Neither would it be a reasonable RFC that tries > to dictate this. > > In any case though, for an actual attacker the spec is just a > suggestion, it might as well say "MUST NOT be malicious". You can > receive any variation of JSON that you must handle within your > computational constraints to avoid excessive resource consumption. Just > as you have to handle any variation of other MIME headers and their > contents. > > Also absolutely nobody is going to write a bespoke "JSON" parser that > strictly adheres to this suggestion and achieves the supposed benefit. > > This is not the only (incorrect) assumption your suggestion makes here > though that has been refuted or been pointed out. > > > Best, > Taavi > > > _______________________________________________ > 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]
