-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>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.
I disagree -- the spec does cover this case very clearly. A DKIM2 system
that receives a message without a valid DKIM2 signature is required to
reject the message.
Since such a system may wish, by local policy, not to reject then the
spec makes it clear that they should not pass the message to anyone
outside of their organisation, because that next system will also detect
the lack of valid system and will not only reject it but may ding your
reputation as well.
>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 is a way of saying that if you want to accept invalid DKIM2
messages then go ahead, no-one can stop you
> 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.
nothing could possibly do that if the intermediate node alters the body
or header fields of a message in a way that breaks the signature
>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.
correct -- which is why the spec's position is that you should reject
the message -- the sending system can work out what has gone wrong, it's
not your problem
the spec then (perhaps superfluously) cautions you not to assume anyone
else will think your local policy was wise -- so don't pass the message
on to strangers
>Delegating that to local policy does not
>resolve the interoperability question; it declares that the
>specification will not address it.
how could it -- criticising any authenticatiom system, not just DKIM2,
by saying "it has no way of dealing with systems that do not use it" is
a waste of our time
>For a problem that is, at its root,
>about interoperability during a multi-year transition, that is the wrong
>layer to leave it at.
what do you want the spec to say ... shame about the signature, pass on
the bad email and hope no bad people are involved ?
>I raise this now because draft-05 has closed several open points but not
>this one
this is not an open point ... the spec says what to do with mail that
does not authenticate. You may wish to do something else ... that's your
local policy. Have fun.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBao9yzmHfC/FfW545EQLuzgCg+AZ++WIWzoZjI+GoKG8PNbxvgpIAn1VR
OkO/XFADvpdTzMYarF51K8cn
=mgck
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
