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