Hello Hannah,
to be clear on scope: my objection to JSON concerns header handling on
the critical path, not body recipes. Body recipes are a separate design
question - my position on their optional status is documented in the
draft and is not the subject of this thread.
And the comparison isn't JSON versus MIME, but JSON versus tag=value -
the DKIM1/ARC style, which has worked reliably for years, to the point
that I reused it in DarkChain.
On parsing: the concern isn't raw speed, it's that JSON introduces a
dependency on parser libraries whose behaviour differs on edge cases
(parser differentials, type confusion) - attack surface that tag=value
does not carry, in a security protocol.
On logging, your "decode it yourself" confirms the opacity rather than
answering it. Routing information that every other transit header
carries in clear now needs a decoding step to be inspected and building
a logging layer to compensate only adds complexity on top of what DKIM2
already introduces.
On memory you confirm the mechanism: holding two adjacent versions in
memory during verification. That is the buffering that tag=value avoids;
DarkChain verifies at constant memory per header and runs on a 2GB
server in tens of milliseconds.
CPU is not scarce in general, but whose CPU? 1&1 and the large
providers, or the university or small associations running a single
server? That is the question RFC 3935 asks: the internet is for
everyone, not only for those who can absorb the overhead.
Regards,
Vittorio
Il 2026-09-09 13:39 Hannah Stern ha scritto:
Hi!
On 9/8/26 09:47, Vittorio wrote:
the architectural objections to base64+JSON are on record in a
submitted draft (draft-moccia-dkim2-deployment-profile) - parsing cost
at scale, loss of streaming with constant memory, opacity in
operational logs. Those are design concerns, not implementation
feedback.
As implementer:
Parsing cost is negligible IMO and less error prone than the usual
relatively ad-hoc syntax around email data (e.g. MIME).
If you are an implementer and want logging to be more readable than
having base64 blobs, you're free to invent your own log format based on
decoded base64/JSON. Logging formats are out of scope for DKIM2 IETF
documents, I'd think.
Memory use seems negligible to me. I've got a proof of concept of a
streaming implementation of recipe rewind for bodies, but with current
servers, the simpler approach (having two adjacent versions in memory
at the same time while verifying) is also quite doable even for modern
large mails.
[...]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
