Hello Pete,
Thank you for the note on tone and your point about the draft's length
is fair: I will cite specific sections rather than referring to the
document as a whole.
On your question let me be precise, because my formulation was looser
than it should have been.
I am not claiming that a message would verify against someone else's
key. The signature covers the Message-Instance header field as literal
text, so the base64 blob is identical for every implementation and the
signature verifies correctly everywhere. The divergence occurs after
that, when the recipe is decoded and applied.
Concretely, with duplicate keys: a recipe object containing two entries
for the same header field name is not rejected by a conforming parser
and RFC 8259 leaves the resolution undefined. One implementation takes
the first, another the last. Both then reconstruct a different previous
header state from the same signed bytes and compare it against the hash
declared by the preceding hop. One reconstruction matches; the other
does not. The verification verdict on a single message is therefore
determined by which parser the operator runs, not by the message.
What makes that more than an interoperability nuisance is that no amount
of verification detects it. A node that reconstructs the entire chain
uses one parser throughout, resolves the ambiguity the same way at every
hop and obtains an internally consistent history. It does not observe a
discrepancy; it observes a valid message (or an invalid one), according
to which parser it runs. The divergence is not between hops, where
verification looks, but between implementations, where nothing looks. No
node in the path can observe that another reached the opposite
conclusion on the same message.
I should add that Richard has stated he will add text to the
specification forbidding duplicate keys. That closes this particular
vector and I think that is the right fix. My concern is the class rather
than the instance: numeric type coercion and tolerated malformed input
have the same shape, in that two conforming parsers may resolve the same
signed bytes differently, with the verdict rather than the signature
diverging. Nor is uniformity obtainable by agreeing on one library:
GHSA-72hv-8253-57qq, in jackson-core, describes a declared parsing limit
enforced on the synchronous path and silently bypassed on the
non-blocking one, within the same version, what the advisory itself
calls an inconsistent enforcement policy. Whether the remaining cases
warrant treatment in security considerations is a judgement for the
group and I would also welcome hearing from others.
Regards,
Vittorio Moccia
Il 2026-09-15 22:26 Pete Resnick ha scritto:
Just on a few points:
On 15 Sep 2026, at 14:50, Vittorio wrote:
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.
Yes, I think Vittorio is correct here. I understand these discussions
can be frustrating at times, but let's keep to the actual technical
issues and give the benefit of the doubt to people's motives.
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.
To be fair, your draft is 100 pages with a great deal of explanatory
text, much implementation guidance, and a good amount of other text
that is normally outside of the scope of IETF technical specifications.
To be respectful of other participants' time, summarizing some of your
concerns would be helpful when people have specific questions, and
citing specific sections of your draft that answer a specific question
would be useful in some circumstances.
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'm not clear on something here: Are you saying that there is a
potential for an attacker to create a recipe and text that would
produce output that, due to a JSON parsing ambiguity, would
cryptographically verify to someone else's key? Even having read 8.3 in
your document, this does seem rather theoretical. There are other
security experts in this group; I would like to hear other support for
this position.
pr
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
