Hannah,
Il 2026-09-14 12:12 Hannah Stern ha scritto:
To me it looks as if you might be playing pigeon chess around these
issues. Or FUD.
I will disregard this. IETF discussions should stay on engineering
merits rather than personal characterizations.
No. I'm asking for a description of actual problems with the mainline
drafts that would ask for an
alternative in the first place.
Then let me be clear about the terms. My draft is not a WG document and
I do not treat it as one; I keep it updated and announce it here and I
raise points on this list when they bear on the base specification. In
this thread, however, you asked for a specific constructive alternative
and for a working implementation. Both exist and both are referenced in
that draft. Declining to look at it while continuing to ask for what it
contains is not a position I can do anything with. Read it or don't, but
then the question stops being a question.
What vulnerability? I don't see a potential exploit if someone is too
strict, "just" an interoperability
issue that would be sorted out early enough.
In a security boundary protocol, node A and node B parsing the same
crafted payload differently is not a benign bug that sorts itself out.
It is a security bypass vector: content can be smuggled past a filter or
a verifier at one hop while a valid signature is preserved for a
downstream hop that reconstructs it differently. You accept that JSON
will produce parsing divergences but treat this as outside security. In
a protocol whose purpose is authentication, that distinction does not
hold: divergent interpretation of signed material at a security boundary
is the vulnerability, not a precursor to one.
JSON parser differentials are a real, well-documented class of
vulnerability, independent of DKIM2: duplicate keys, extreme numeric
precision, type coercion and tolerated malformed input.
I'd personally not hesitate to re-implement the needed JSON subset
parsing/generation manually
That does not remove the problem, it makes it worse. It multiplies the
number of non-identical implementations of the same format and therefore
the probability that two nodes resolve the same input differently. A
chain of verifications is only as strong as its weakest link, and in
multi-hop that is a routine condition, not an edge case.
If I want to rewind one step in "mainline" I also have to consider only
the r= on the latest
(not all) Message-Instance. No need to "preload" all for that.
The mainline packages the recipe into a single JSON object with two
properties: h, to rebuild modified header fields, and b, to rebuild the
modified body. That object is base64-encoded and placed in the r= tag of
the Message-Instance. To read h you must base64-decode and parse the
whole object, which may carry literal body lines. A tag-value field such
as DKIM2-Mod is separate: a verifier checking whether the previous hop
declared its header changes honestly reads the header declarations and
reconstructs no body at any point. That is the difference - selectivity,
not step count.
You can decide to do them synchronously (as we will do probably),
asynchronously (e.g. for
assessing whose reputation you need to take into account), or not at
all.
The last case places the chain of custody outside verification, which
returns those properties to trust.
My position is that a one-step rollback to i-1 is sufficient: it detects
a predecessor that misdeclared its header modifications, and each honest
hop performing the same check makes the chain self-validating in
transit, without any node reconstructing the full history. End-to-end
reconstruction (as advocated on this list) is the expensive path,
because it requires decoding and holding every recipe in the chain and
reconciling them together, back to i=1. With tag-value the full
traversal would be inexpensive either way; the question is what the
format costs when someone does want it.
People would probably rather DDoS your DNS client than manage to DDoS a
JSON parser.
Even under 2GB VPS constraints.
That is an unsupported conjecture and DNS-layer attacks are
comparatively easy to mitigate. It is a deflection, not a rebuttal of
resource exhaustion on the parsing path.
It doesn't. People working on the mainline drafts/their predecessors
proved that.
A message reference or a document section would let me address the
argument rather than the claim.
Regards,
Vittorio Moccia
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
