Hi Hannah, hi all, 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.
It's not the task of the OWASP to forbid anything, but it is the
task of the IETF to define secure protocols.
Regards,
Timo
It looks like Hannah Stern aimed to say:
> Hi!
>
> Thanks for coming back to me.
>
> Ahead: I don't think OWASP generally forbids/discourages REST services
> with JSON mapping for request/response data.
>
> I'd expect it rather to give guidance how to do that safely.
>
> The same guidance can be used by DKIM2 implementers to handle JSON safely.
>
> On 9/22/26 14:57, Timo Gerke wrote:
>> Hi Hannah,
>> hi all,
>>
>> I am reffering to OWASP Top 10 A06:2025 Insecure Design [1]
>> and OWASP Top 10 A04:2025 Cryptographic Failures [2].
>>
>> 1. Strict, Deterministic Input Validation: OWASP mandates
>> unambiguous data models. By forcing nested JSON, the spec
>> imports RFC 8259, Section 4 (duplicate keys are "undefined").
>> This structural ambiguity actively provokes flawed input
>> validation.
>
> I think the DKIM2 draft itself forbids duplicate keys. So IMO the spec
> forces implementers to check if their JSON parser already generically
> handles that, and if not (e.g. ours returns a multimap for JSON
> Objects), validate that in domain specific code.
>
> For header recipes we also disallow "logically" duplicate keys (that
> differ in case, so aren't duplicate keys in the JSON sense), also
> requiring implementers to check for this.
>
> IMO with that, input validation is clearly and unambiguously defined at
> this point.
>
>> 2. Bounding Worst-Case Resource Consumption: The guidance
>> requires protecting gateways against resource exhaustion.
>> Nested JSON layouts allows an algorithmic complexity DoS
>> attack.
>
> Implementers can limit JSON parsing depth to the very limited deth of
> the specific JSON the spec allows.
>
> In addition, even with unlimited depth/very high depth limits, I'd
> venture that a parser can be implemented with O(n + d) RAM and CPU (n =
> input size, d = nesting depth).
>
> I'd venture a validator (generic JSON, or even DKIM2 specific already)
> that doesn't produce output can be implemented in O(d) RAM and O(n) CPU.
>
> The deepest nesting we have is object (top-level) > object (within "h")
> -> array (of steps per field key) -> object (one-item, either "d" or
> "c") -> array (either 2 line numbers of 1+ strings) -> number/string, so
> a DKIM2 implementer could choose to use that as limit.
>
>> 3. Invariance of Security Controls: Data interpretation must
>> remain identical across all layers. The spec encourages
>> parsing differentials between security gateways and downstream
>> systems, directly bypassing the cryptographic integrity of the
>> signature.
>
> I don't see that. The subset of JSON we generate/parse is limited, which
> makes ambiguity less likely than generic JSON, already.
>
> If a Verifier should still happen to parse JSON differently from what a
> Signer expects parsers to "understand", they'd just fail verification of
> previous message instances even for a valid mail. A Signer can abuse
> parsing differences only if it manages to trigger divergent JSON parse
> paths that both/all end up with the correct previous hash value recorded
> in the M-I; i.e. the Signer would need to produce a sha256 (or 512)
> collision.
>
> The overarching signatures in D2-S don't parse/generate JSON but just
> use a simpler canonicalization of the _textual_ M-I/D2/S fields as input
> for signature generation/verification.
>
> So that's at most an interop issue, but not a cryptography bypass.
> Recipe "misunderstandings" are caught by the cryptographic hashes and
> are irrelevant for top-level signatures.
>
>> To satisfy the guidances, a secure architecture mandates a
>> flattened, linear O(n) layout, in my opinion.
>
> In the end we still need to represent a nested data structure (with
> limited nesting), either in JSON or in some custom syntax. IMO interop
> and bug risks are not better for custom syntax.
>
> With ad-hoc quoting/delimiting at least implementation bugs are IMO
> perhaps even more likely than with a representation for which
> off-the-shelf good quality code exists.
>
> JSON with nesting limit is also O(n), so an O(n) requirement doesn't
> force a decision between the JSON based representation and an ad-hoc
> representation.
>
> The only issue _I_ can theoretically come up with is: We allow
> additional entries in the top-level JSON object besides "h" or "b".
> Those could theoretically be extra deeply nested.
>
> The smallest way to produce deep nesting would be [[[[[[...]]]]]], for a
> nesting depth of size/2. (I.e.
> {"h":correct_stuff,"extension":[[[[...]]]]}). For CPU stack based
> parsers that could lead to a crash by hitting the stack guard page if
> generic parsing depth isn't limited well enough. That's not nice, that's
> DoS.
>
> Realistic mitigations without changing the spec: Parser depth limits.
> Fast good JSON implementation (they exist). And implicitly because MTAs
> usually have overall header size limits.
>
> So one outcome of this discussion could IMO rather be: Change the spec
> to forbid additional items in the top-level JSON Object. Unless a
> further update would add _specific_ other options there, but that would
> be an interop nightmare anyway because there's no feature negotiation
> between Signers and Verifiers. So IMO allowing extensions there doesn't
> make much sense if any.
>
> That would close the potential issue with extension entries and
> definitely allow parsers to apply the low nesting depth limit that's
> just enough for standard recipes.
>
> Hannah.
>
>
> _______________________________________________
> 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]
