Thomas
You raised good points, but I don't think it is that complex at all.
We have a mailing list server (MLS) product and I feel that if we want to
accomodate DKIM, there are some things that we can do:
- The MLS should use SSP to pre-emptive email subscribers
with restrictive domains. This would be done at the
subscription level. It will help protect the domain owner
from any possible malicious abuse from their own employees,
users, students, or bad actors.
- If the MLS is prepared for signing, it should use SSP to
determine which domains allow it.
- If the domains allows it, the MLS should be allowed to
STRIP broken signatures or signatures it will break by
resigning and then resign itself. NOTE: This is currently
against DKIM-BASE specification (No stripping).
In short, iff the DOMAIN doesn't care about the potential abuse of its
domain by promiscuously or blindly sending it to a MLS, then the DOMAIN
should be explicit with relaxed SSP policies saying it really doesn't care
or not use DKIM at all for this particular mode of operation. At this
point, the receiver will treat it like any other mail because the DOMAIN
simply doesn't care one way or another.
To me, it doesn't make sense for an organization to invest in a new SECURITY
framework only to leave the key under the "Porch Potted Plant" thus breaking
its own new DKIM security policies for the organization. (See ** below)
With just DKIM-BASE, the threats are well documented. See the TA draft.
SSP is about offering a possible solution, if only partial, to this problem.
The main issue is feasibility. If you want DKIM to work via a MLS, then I
think it is naive to believe (speaking in general) it will work very well
without some sort of MLS change to consider the redistribution process of
original DKIM signed mail.
** Take for example this mailing list:
There are signatures here from various people; Mike, Jim, Arvel, etc.
Guess what?
All of them will fail the DKIM test because the mailing list server hosting
IETF-DKIM is breaking the integrity of the message without correcting it.
Yet we continue the downlinks ignore it and accept it - the CRY WOLF
syndrome.
What is to prevent the BAD ACTOR to use this "cry wolf", borrowing Mike's,
Jim's, etc signature and use it in ATTACKING other systems?
Or even here, how will I know that the post here from Jim or Mike actually
come from them?
In short, what this will promote is a damage DKIM concept where receivers
will ignore DKIM altogether just like users ignore Popup Errors from MUA
saying a SMIME/PGP message has failed.
This is what you want to avoid.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Thomas A. Fine" <fine(_at_)head(_dot_)cfa(_dot_)harvard(_dot_)edu>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Monday, September 11, 2006 2:57 PM
Subject: [ietf-dkim] SSP and mailing lists
Some here have proposed adding a clause statement to the
standard all-signed policy that waters it down to effectively
mean that receivers might get valid messages damaged by
gateways, and adds a new policy that says a domain guarantees
it's addresses will not go through non-compliant gateways.
The standard policy becomes to weak. It doesn't mean anything
besides "please accept mail that looks like it might be from us.
It means the domain remains unprotected.
And who could set the stricter policy? The odd bank or tightly run
corporate entity maybe. Who could not? Universities, ISPs, email
address providers, technical corporations -- all these groups expect
their users to have some amount of freedom participating in mailing
lists.
So if the only way a domain can set a policy that permits* recipients
to drop unsigned or broken mail is to set a policy that it will
not use non-compliant mailing lists, then this is doomed to failure,
and I would go so far as to say that nobody would bother with DKIM
at all, because they couldn't use it to protect their domains.
One serious point about a policy such as the one described above is that
it seems to attempt to describe the transitional state of the entire
internet, rather than the transitional state of a particular site. As
such, almost no one could have any other policy besides this until DKIM
acceptance approached 100%.
Maybe this is just a question of wording. Perhaps everyone would be
satisfied with these two policies:
"I sign all email"
"I sign all email, and do NOT permit email through any body or
signature altering gateways"
Now this might accomplish what is desired, but it reads entirely
differently. The first is still strong, not weakened as has been
suggested. And they describe what the site does, not what the
internet is doing. The second statement is very strong. It
may be rarely used but I can see it's utility. It would probably
be more useful on a per-address basis than it would be on a
per-domain basis.
First, note that basically what this almost seems to be saying is that
the envelope-from must match the From: and/or DKIM address.
Second, note that this may only useful in a policy-first environment.
In the current spec, the assumption is we never know the policy if we
have a valid key. So without gutting and reworking that fundamental
concept (which might be a good thing), such a policy of more strict
email control is not really implementable.
So basically, I think that policy should be designed for the long
term steady state, and not designed primarily for a transition
period. The implementors can take care of the transition.
tom
* another spin on who dictating versus recommending versus asking is
this: an all-signed policy gives the sending domain's _blessing_ to
the receiver to drop the mail on the floor if it is not verifiable.
It doesn't say they have to do it, but it says that it is fine to
do that.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html