Hello.
The chain-of-custody model in draft-05 shares a property with any DKIM2
design built on the same foundation: it assumes the modifying parties on
a path participate in the chain. Section 7 addresses the transparent
case explicitly - an MTA that changes nothing "need not be made DKIM2
aware." That is correct and welcome. What is not addressed is the other
case: a node that is not DKIM2-aware and does modify the message - a
list rewriting a Subject and appending a footer, a gateway altering the
body. This breaks the chain and it is not an edge case; during
coexistence it is the common case, for as long as any non-participating
node sits on ordinary delivery paths.
When this was raised earlier, the response was that such a message falls
to local policy. I want to be precise about why that answer does not fit
the problem. Local policy governs what a receiver does with a message -
accept, reject, flag. It cannot govern whether two implementations
interoperate across a path that includes a node neither of them
controls. A chain broken by a non-participating node produces, at the
next hop, a verification failure whose cause cannot be determined from
the message alone: it is indistinguishable from an attacker who altered
the same content after signing. Delegating that to local policy does not
resolve the interoperability question; it declares that the
specification will not address it. For a problem that is, at its root,
about interoperability during a multi-year transition, that is the wrong
layer to leave it at.
Bron has just raised the adjacent case - a signature that verifies but
uses an algorithm a downstream verifier does not understand - and asked
for a way to signal that failure explicitly rather than let mail
disappear silently. John's reply already sketches the shape of the
answer: a feedback mechanism reporting, per signature, "good, bad, or I
dunno." The non-participating-node case is the same shape in a more
severe form and it needs exactly that third value. When a prior seal is
broken by a node that never entered the chain, the downstream hop cannot
determine the cause from the message alone - "I dunno" is the honest and
only correct verdict - yet it still needs to record that the break
predates its own handling and carry the message forward flagged, rather
than reject it blind or accept it without record. The mechanism Bron and
John are converging on for the algorithm case answers this one too.
I raise this now because draft-05 has closed several open points but not
this one and because it is structural: it sits in the foundation both
the base specification and any conforming profile share, not in any
optional layer where the two differ.
Regards,
Vittorio Moccia
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
