----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
To: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
Suppose there is an ISP who signs for two customers: company.com
and mailinglist.com using this third party delegation
mechanism that it being touted. company.com and mailinglist.com
make a SSP records that says that ISP.com is their signer.
So lets assume the declation as proposed in DSAP
company.com
OP=NEVER or OPTIONAL;
3P=ALWAYS;
3PL=ISP.COM
mailinglist.com
OP=NEVER or OPTIONAL;
3P=ALWAYS;
3PL=ISP.COM
Now lets construct some messages:
// normal from company.com
From: foo(_at_)company(_dot_)com
Dkim-Signature: d=isp.com;
// what is the dkim-signature asserting here:
From: foo(_at_)company(_dot_)com
Sender: mailinglist.com
Dkim-Signature: d=isp.com
How does the recevier know who isp.com is signing on behalf of? The answer
is that it doesn't.
Ahhh, but it doesn't care because the customers don't care, via the above
consistent policy declaration.
So let's send this from mailinglist.com through their authorized
submission server:
From: president(_at_)company(_dot_)com
Sender: mailinglist.com
DKIM-signature: d=isp.com;
First, the presumption here is that president(_at_)company(_dot_)com has
subscribed to
some mailing list where he should now be very aware the door is wide open to
exploitations.
Second, the presumption here is that the mail is that we have a single
source signing domain network, and that the mailinglist.com server is
outside the signing domain network.
COMPANY.COM ---->
ISP.COM
MAILINGLIST.COM ---->
So far the policies are consistent. But what is more important is the
SUBMISSION process. Don't forget that. The ISP does have control here.
Is mailinglist.com allowed to assert president(_at_)company(_dot_)com? No.
Yes, because president(_at_)company(_dot_)com has subscribed to mailinglist.com
it has
opened the door to exploitations. Its like you giving your driver's license
to your teenage son so he can go drinking or to some night club. You are
taking chances.
Does the signer have any way to allow the receiver to tell which
address it's signing on behalf of? No.
It doesn't care.
Is this a threat to company.com? Yes.
Absolutely, but the boss should of known that by using his company.com
domain promisculously on other systems.
Does ISP.com have any way to police this? No: it doesn't know
whether president(_at_)company(_dot_)com is subscribed to a mailing
list at mailinglist.com or not.
The ISP.COM does have a way to policy it if the DOMAIN declared it in its
policy or there is a contractual policy between the ISP.COM and DOMAIN not
mix apples and oranges.
Also, the ISP.COM has control thru the SUBMISSION process. It sees mail
coming in from the mailinglist.com, not company.com. Thats a major piece of
the protection here.
This is a *much* bigger security hole than just a submission
authentication problem. It's allowing companies whose only
common business link is their provider to freely spoof each
other in a way that the ISP can't control. That's a problem.
I don't agree, Mike.
This issue is no more, no less an implementation issue. The ISP.COM can
control the process, but also the domains themselves can't have all the cake
and eat it too. If it wants protection, against external abuse then he will
need to be less promiscuous about his domain usage. What if the
mailinglist.com does other things to the mail, such as destroy the integrity
so that DKIM-BASE will fail anyway? At the very least, if the domain
wanted to do this right, it would have a policy such as:
company.com
OP=NEVER or OPTIONAL;
3P=ALWAYS;
3PL=ISP.COM; MAILINGLIST.COM
This allows for the mailinglist.com to maybe RESIGN his mail, the policies
would be consistent for the verifier and its all good.
But if the domain didn't care at all by subscribing to this and other
mailinglist.com services, then why even have a policy at all? He doesn't
need one.
If anything come outs of this discussion is to show the DKIM-BASE is less
safe without email signature policies because anyone (ISP.COMs and his
uplink, and his uplink, and so on) can sign without restrictions.
It also saws that ISP.COM need to be more in control of what they sign once
DOMAINS want it to be used, either directly themselves and they are using
the ISP.COM to route mail, or indirectly with the ISP.COM taking on some
duties or offering DKIM services.
The idea of an ISP.COM just blindly signing mail as a 3rd party is going to
create some major problems without some level of controls.
I can understand how we want to allow this to happen, but we also need to
understand that there will be domains that do not expect this to happen, not
if they are going to invest in DKIM.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html