On Sun, 2005-10-30 at 09:29 -0600, Arvel Hathcock wrote:
1. Alice works for Alice-Corp who publish a policy to the effect
that they and only they sign all their outbound mail.
2. Alice posts a message to Foo-list which signs the message
itself and drops Alice's signature.
3. Bob receives the message from the Foo-list, signed by the list.
4. Bob looks up Alice-Corp's ssp assertion and considers the
message as having a bad signature.
5. In order to allieviate this problem Alice-Corp are forced
to weaken their policy to allow 3rd party signatures to be
accepted by Bob.
I don't consider this a problem per se. In this case, Alice-Corp has made a
conscious decision to refrain from the maximum possible protection in order
to allow Alice access to a mailing list.
In other words, Alice must decide to no longer protect the email-address
in order to permit the use of the mailing-list and be independent of the
provider. This of course places Alice at risk when a reputation system
is based upon the mail-address. (This is not just supposition!)
Without some type of reputation system based upon either the signing-
domain or the email-address, DKIM provides little, if any, value.
There will be an extreme disruption in email-services when the email-
address is considered suitable for accruing reputation. At such a
point, the email-domain owner for Alice must disallow signatures by
other domains. SSP already requires an email-address be associated with
the signing-domain!
A practice could ensure email-addresses are independent of the domain-
signature where only an opaque-identifier is able to make a binding to
the address as a means to prevent spoofing of a prior correspondence.
With the opaque-identifier approach, it would only be practical for
reputation to accrue on the signing-domain, as the email-address would
be allowed to change. This would ensure mailing-lists services are not
affected, nor would would users be forced to use the email-address
offered by the ISP.
There should be a simple DNS lookup that indicates whether a domain is
the subject of a phishing attack.
I like the idea of doing a simple query for an A record at:
<domain-in-questin>.phished.ftc.gov.
In the case for a phish attempt, the signing domain will play a role in
determining whether the message is a phish. The items that must be
checked to catch the phish attempts are not limited to the From email-
address. SSP will not make a dent in phishing, but will significantly
disrupt email services for no good reason.
So a decision was made at Alice-Corp that granting access to the list
for Alice is more important than an Exclusive policy. This was their
decision to make and DKIM is flexible enough to allow for it.
This decision to disallow the use of other domain-signatures is easily
coerced. The use of the opaque-identifier prevents this type of
coercion, while at the same time deals with a problematic Zombie
situation, and an abusive message replay threat. The message replay
threat is still not covered adequately in Jim's threat review. This
replay issue was raised in Russ's initial overview of IIM and
DomainKeys.
Other companies may decide that it's unwise to completely relax policy on a
domain-wide scale simply to allow mailing list use. For those, putting list
participants on a separate sub-domain could solve the problem.
Claiming this to be a freely available option is being rather naive, as
it only takes the arm twisting by a few major players where this becomes
no longer a choice. As a result, the ability to use email services will
have been lost as well as an ability to use an email-address independent
of the provider.
Get rid of the SSP policy strategy that attempts to "protect" email-
addresses and instead use a scheme that attempts to protect DKIM. Allow
the current freedoms provided email-addresses and then DKIM has a better
chance of being deployed without arm twisting. The real tool that will
eliminate most of the problems would be a opaque-identifier method that
tracks problematic accounts independent of the email-address. Locking
everyone to their provider is not a good direction to take email.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org