Douglas Foster writes:
> In operation, the trust issues have been more difficulty to resolve than
> expected.

This is mostly because people have been trying to find a system wide
solution to this problem. I.e., trust relationship that would apply to
everybody in the recipient end of the system.

Such trust does not exists.

It is trivial to do when you move your trust relationship to be per
user basis. Valid email forwarding happens when the user requests it
to happen. This can be when I for example ask a email service like
iki.fi. netbsd.org or ieee.org to forward emails from there to my
final email address.

If some random domain (like google.com or microsoft.com) starts to
forward emails to me, that is something that is unwanted, as I have 
not requested it myself.

Because of this when email is forwarded to me and ends up in my final
mailbox, I do not trust google.com, or microsoft.com ARC signatures,
but I do trust iki.fi etc ARC signatures, as I trust those services
(If I would not be trusting them to properly generate ARC signatures,
I would not ask them to forward emails to me).

> A malicious ARC set may be disguised when it is routed through a
> trusted forwarder that adds a second ARC set which merely restates the
> fraudulent information in the first set.

No. The trusted ARC forwarded will sign authentication information how
it saw it when it received the email. If the DKIM signature is broken
he will sign information that DKIM signature was broken. If the SPF
did not match then it will sign that SPF verification failed.

It does not care what the earlier ARC signatures said. Same thing in
the my end system. My end system do not care that there are other ARC
signatures there are, it only cares what my trusted ARC signers saw
when they received the email. If the DKIM signature is broken now, and
was broken when iki.fi saw the email, then DKIM signature is broken.
If the DKIM signature is broken now, and was correct when iki.fi saw
the email, I can trust that (the email signature got broken most
likely because iki.fi considered email as spam and marked it so by
explictly modifying the subject).

If the SPF checks fail now (like they will most likely do as email was
forwarded), but iki.fi says SPF checks succeeded when it received the
email I can use that information when deciding whether the
authentication was valid.

> After an innocuous change invalidates a DKIM signature, a malicious
> downstream entity could insert malicious content to take advantage
> of the upstream trust.

When email is forwarded by trusted forwarders, it usually takes known
path from the trusted forwarder to the final destination. For example
in case of iki.fi, it will directly send it to my email server. You
should not forward your emails through malicious downstrem entities...
Note, that the user is the one who sets those forwardings they do not
appear at random, so user can decide which path the email will take
from the trusted forwarder to final destination.

> Overall, the ability to establish a
> reliable set of trusted ARC sources has proved very difficult, while
> the volume of trustworthy ARC sets has been low.

Global number of trustworthy ARC signers shall be zero forever, and
should be so.

I do trust iki.fi. There is no reason for you to trust iki.fi, so we
can never agree on globally trusted signers.
-- 
[email protected]

_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to