On Mon, 2006-08-28 at 00:25 +0200, Frank Ellermann wrote:
> Hector Santos wrote:
>
> It can be both correct: Let's take a realistic example, GMail
> starts to offer forwarding, but adds some ads plus their own
> signature, destroying the signature of bank.com. If we have
> a couple of "MUST reject" and implementations actually doing
> this they might give up. Something has to give, bank.com, the
> munger, the verifier, or the user.
>
> With mail I expect the worst, the crap is dumped with a big
> red "fishy" icon into the mailbox of the unhappy user. The
> user will delete it unread, bank.com will give up its SSP,
> the verifier gives up to use DKIM... tell me why I'm wrong.
I agree with you on this point. A message signed by Gmail can't be
accepted on the basis their signature. Gmail has the same problems
plaguing any large domain. Some other acceptance criteria must be used
which makes DKIM fairly useless should a limited assurance of a
signature via policy be the only benefit.
Dave Crocker suggests policy be limited to "I sign everything" without
any other clarification. Is this domain a phishing target where they
are willing to forgo services and suffer delivery issues? Otherwise
this assertion allows bad actors to simulate situations causing
signature damage to gain acceptance.
This limited policy does not offer a piece of information related to the
handling of their signature. "I do not utilize non-complaint services
that damage the signature." With that piece of information, a solution
for an extremely small percentage of domains seeking protection from a
phishing problem is promised. But this is a false promise.
As other have pointed out, look-alike and cousin domains breeze past
this mechanism as if it were not there. Delivery problems continue and
phishing will become even more convincing. Hardly a good choice for
anyone under attack to have made. : (
There is a different strategy that should work without suffering the
same delivery issues and yet defeat look-alike attempts. While
accountability starts at the DKIM signature, trust starts at the
2822.From address. The DKIM signature MUST provide extremely clear
semantics regarding an assurance of the 2822.From address being valid.
After all, people will not even see the signature in most cases, and it
could be a look-alike even if they did.
Before an MUA even attempts to ascertain the validity of the signature,
the signature MUST provide an assurance the 2822.From address is valid.
Otherwise, the recipient should ignore the signature as completely
meaningless. When the 2822.Form address is assured valid by the signing
domain AND this address is also in the address book, then verify the
validity of the signature. There is no reason these assurances need to
be limited to just email-addresses within the same domain. The DKIM
signature can easily play the role of an email-certificate.
Trust starts at the 2822.From address where the signing domain must be
associated with the 2822.From address for the signing domain to be
trusted. There MUST be an assurance that the 2822.From is valid as well
before anything can be trusted at all. With this strategy, there is no
need to indicate whether all messages are signed for the sender and the
recipient to obtain a safe and tangible benefit.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
