On October 28, 2005 at 23:57, Stephen Farrell 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.
So, is there an error in the above?
I think another example is needed to show that the scenario is
not just dealing with mailing lists. For example:
1. Alice wants to send an e-card to Bob using e-cards.domain.
2. After creating her e-card, e-cards.domain sends the card
(via email) using a From supplied by Alice.
(Side note: E-cards could verify Alice's From beforehand
to make sure it is legit).
3. Bob receives Alice's card, with his MUA showing it is
from Alice and the Sender is e-cards.domain, which the
MUA may, or may not, show.
What problems does this scenario pose to DKIM (as DKIM is currently
defined):
A. Problems wrt to E-cards.domain:
(1) E-cards.domain cannot DKIM sign the message and expect
it to pass validation unless Alice's domain allows 3rd-party
signing. Since SSP is only bound to From, E-cards would
be discouraged to do any signing to avoid risk of message
not getting delivered.
(2) If Alice's domain has an exclusive (non-3rd-party) signing policy,
E-cards is screwed, regardless if it signs or not. Since
Alice may have paid for the service, this is a big concern
for both parties.
B. Problems wrt to Alice:
(1) If Alice's domain does DKIM, it would need to allow 3rd-party
signing. Unfortunately, this would open Alice up to spoofing
by malicious domains (as noted in past messages to ietf-mailsig
and ietf-dkim). This would encourage Alice to drop DKIM so
she can utilize services like E-cards.
(2) Alice may not have any say on her domain's DKIM policies, such
policies are determined by the mailbox service provider. Such
policies may not be known to her. If the SSP is exclusive,
problem A1 kicks in. If SSP allows 3rd-party signing, problem
B1 kicks in.
Problem B2 also raises another potential problem, something I believe
Doug has been trying to point out. With DKIM policy controled by the
domain owner, and not the mailbox users, a mailbox user may be held
"hostage" by the domain owner on how the mailbox user can use their
account.
For example, if the domain owner specifies an exclusive non-3rd-party
signing policy, someone like Alice would be prevented from using
services like E-cards or any other legitimate masquarading functions.
The domain owner may care less of such uses since it deems exclusive
non-3rd-party signing critical to "protect" its domain.
A side example, I always send out mail via my ISP with originating
addresses completely different from my ISP account. My ISP has no
problem with this since it can utilize my IP address to determine
if I am a customer. However, if my ISP enables DKIM signing, I may
be screwed, along with other users that utilize a permanent OA in
their email. My ISP could force me to either use the email address
they have given me for their domain (which I do not want to use) or be
forced to always submit my mail through systems hosting my OA domain
(whose reliability may not be as good as my ISP).
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org