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
