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.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail:[email protected] | Web:www.mail-and-media.com www.gmx.net www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr.
Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt,
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
