On Tue, Sep 15, 2026, at 15:50, Vittorio wrote: > > 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.
a) what's a security boundary protocol b) citation needed Sometimes it is a benign issue with no security considerations. Sometimes it's a critical security vulnerability. You can't make blanket statements without doing security analysis. You especially can't fall back to blanket statements when said security analysis has been done by somebody else and they showed why it's not a problem in this case. > 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. Each hop validates all the signatures themselves. There is no trust in this protocol, only verifiability. A non-careful hop can decide something is valid; and even modify it having trusted its interpretation of the message, but unless it can recreate the source message normalized-byte-identical to the way the final validator would validate it, the chain will break. I would counter with a "please provide an example of how an attack would work". As in, an actual attack, not a generic statement about classes of attacks. > 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. Again, example please. > 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. Yes, JSON has engineering limitations, you have to demonstrate that they are relevant to the use to which it is being put. Concrete has known weaknesses under tension, it doesn't stop people creating perfectly sound constructions out of it. > > 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. Incorrect in DKIM2's case. Each hop walks the whole chain, and independently verifies the previous hop's work. One weak hop doesn't weaken the later validators. > > 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. Assuming all hops are honest is a chump's game, see ARC. Every sensible site is going to follow the same basic pattern I suspect. 1) is the content objectionable? 2a) if not, assume mostly goodness, scan changes for weirdness, deliver to user. 2b) if unwanted, figure out who did the bad, and add them to your naughty list. > > 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. What would you accept as a rebuttal other than throwing away JSON? What proof would be sufficient to persuade you? Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
