ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Delegating responsibility: a make vs. buy designdecision

2006-08-18 11:31:53

----- Original Message -----
From: "Wietse Venema" <wietse(_at_)porcupine(_dot_)org>


In case (1), when the trusted signer-domain matches the author-domain,
I might trust that the mail actually originates from the rfc822.from
domain. In case (2), when the trusted signer-domain is not related
to the author-domain, I might trust that mail was distributed by
the mailing list that I subscribe to, or that it was processed by
the malware removal service that I subscribe to.  Thus, in (2) the
author-domain (rfc822.from) is relatively unimportant compared to
the signing-domain; even in (1) its importance is only secondary.

Where is all this TRUST coming from?

This is completely flawed logic subject to major high probability abuse, not
low probability.  How can you continue to ignore this?

I highly doubt you can prove otherwise, where I on the other hand I prove it
100% it is flawed.  I will have 100% trust, no "might trust" when I check a
2822.From: domain policy and it states a policy about how its mail is
tampered with (signed or not signed).  I'm not going to trust a 3rd party
signer for absolutely no reason whatsoever unless the OA domain vouched for
it in some "Allow List."   That would be a highly dangerous framework if
done in an uncontrolled manner and there is no way you can not prove it
would be exploitable.

Folks, we are continuing on this movement of allowing anyone to tamper, sign
or do whatever they want with mail, including adding/changing information to
headers that could destroy and change operations.  How people expect this to
be tolerated in a wide adoption is surreal!

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com







_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>