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]
