Hi
Following the -07 announcement, I want to bring a concrete,
production-observed case of the undifferentiated authentication failure
the graduated enforcement model addresses, because it is easier to
reason about the enforcement question from a real path than in the
abstract.
I sent a message to this list, signed at i=1 by my own domain. The list
software is not DKIM2-aware: it adds no signature, but it does modify
the message, rewriting the Subject line and appending a footer to the
body, as most list software does. When the message returned to me as a
subscriber, verification of my own i=1 signature failed - both header
content and body no longer matched what had been signed at origination.
Nothing was wrong with the signature, the key, or the signing process.
The failure is fully explained by a legitimate, well-understood
transformation performed by an intermediary that does not participate in
DKIM2. Yet from the verifier's side, at the moment of checking, this is
indistinguishable from an attacker who altered the same content after
signing. The cryptographic evidence is identical in both cases.
This is the crux and it is worth stating precisely: "content changed
after signing" and "content changed after signing, maliciously" produce
the same signal, and a verifier cannot tell them apart from the message
alone. No reconstruction mechanism resolves this. Body or header
recipes, and any per-hop modification-declaration mechanism, all depend
on the modifying party participating and declaring what it changed. A
non-DKIM2 node does neither, by definition. The ambiguity is not a gap
in the reconstruction machinery - it is what "the modifying party did
not participate" means. It cannot be closed after the fact by any
mechanism, however capable.
This is why the enforcement distinction matters. Where a verifier has
cryptographic evidence that a declared DKIM2 participant modified the
message and failed to account for its own changes, rejection is
justified: that party is demonstrably dishonest. The case above is not
that. Here a single valid originator signature covers a message whose
body and headers were both altered afterward - the footer changed the
body, the injected List-* fields and rewritten Subject changed the
headers - by a party that never entered the chain and signed nothing.
There is no dishonest participant to hold responsible, only a legacy
node in the path. Applying a binary reject to this class does not
improve security; it rejects legitimate mail whose only fault was
transiting infrastructure that does not yet implement DKIM2. As long as
any non-participating node can appear anywhere in a delivery path -
which, as the announcement noted, will be the case for a long transition
- this is routine, not exceptional, as this list's own path
demonstrates.
What seems necessary is a way to record that the most recent signature
failed to verify and to deliver the message anyway, without asserting a
cause the verifier cannot determine - a per-hop result record carrying
"previous signature failed, cause undetermined" that travels with the
message, rather than forcing a binary accept/reject decision that cannot
express it. This is the direction -07 takes; I raise the case here
because the failure is structural, it is already observable in
production and the base specification offers no normative guidance for
this class of failure - leaving the accept-or-reject decision to
uncoordinated local policy, with nothing to discourage rejection of mail
whose failure cannot be attributed to any participant.
Regards
Vittorio Moccia
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
