Or 6, switch to a non-exclusive domain. Stephen, this has been repeatedly brought up by me numerous times and did so again in one my last recent messages.
http://mipassoc.org/pipermail/ietf-dkim/2005q4/000940.html However, I see it as a good thing, not bad. The issue is in step 2 where ALICE incorrectly begins to use her exclusive domain for exclusive signing only outside the DKIM security protective blanket for exclusive operations only - a very desirable mode of operation. She is breaking her own security by using this domain outside the scope of her company policy. You have two developing situations with DKIM: 1) DKIM Exclusive policies will correctly force high-value domain users to avoid using their exclusive domains in non-company related PUBLIC areas. This is GOOD if they want to protect the domain. This is why it is prudent that SSP CHECKING is done to protect the domain with EXCLUSIVE policies. 2) As part of the protection scheme, the DKIM-READY mailing list will need to double check subscribers using DKIM domains with EXCLUSIVE policy and reject these subscribers. This might be done to PROTECT the high-value exclusive policies. For example, a mailing list subscription processor might say: Sorry, you can not use this email domain to subscribe to this list due to the exclusive DKIM policy defined by the domain. Please use another email domain address. In my view, this is a perfectly valid policy that a company may have to mandate exclusive domain operations for company users or employees. It might seem like a "nuisance" for some to be forced to use another domain for outside public activity, but that ought to be a company policy decision. If the company does not need or care for this exclusive level of protection, they can switch to a NEUTRAL policy. This is where Earl's idea of having a "list of authorized 3rd party signers" might help this particular process. But this is currently not part of the specs. I think it or something related to it should be. In short, if you use an EXCLUSIVE policy, it should be 100% honored across the board in order to get the expected protection it offers. This will be a blessing for high-value domains who absolutely do not want their domains to be used outside business activity and only for direct 1 to 1 transactions between companies and their customers/users. If a company is using a service bureau or clearing house for distribution customer mail, then this has to be done in a pre-arranged authorized DKIM signing manner either with its own exclusive 3rd party signing, or multiple signatures. It is a valid implementation issue that was envisioned early on. I see this as a GOOD thing, not BAD. It is the #1 level of protection DKIM can offer. It requires SSP checking at the protocol level. In my view, without this, DKIM is a weak protocol with very little added protection value. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ---------------------------------------------- Stephen Farrell stephen.farrell at cs.tcd.ie Fri Oct 28 15:57:47 PDT 2005 In an offlist exchange with Doug I asked him whether he thinks the following scenario is an example of his perceived problem with ssp. He said it is an example, so I wanted to check with the list about this. 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. So, is there an error in the above? (E.g. does the problem go away if both signatures are maintained with the message, or does it just get more messy, but remain a problem.) If the above is possible, how should/can it be avoided? Note: even if this is a valid problematic scenario, I don't believe we need to fix it right now, but we should recognise it as a problem that needs solving. Stephen. _______________________________________________ ietf-dkim mailing list http://dkim.org
