Thomas A. Fine wrote:
Hi,
(This is my first post here. I've reviewes this subject in the archives
quite a bit, but not exhaustively. If I've missed something obvious,
please smack me down.)
Welcome, Tom. No smack-down will be needed. :-)
The procedure I've seen outlined here for policy discovery is deeply
flawed. As I understand it, you look at the From domain, and
check it, if you find nothing you check the pointer, and if you
find nothing then there's no policy.
Here's the problem: foobar.com expects that all of it's
mail will come from foobar.com, and sets a policy at _dkim.foobar.com
that states that everything coming from there will be signed.
Some spammer forges mail from joe(_at_)subdomain(_dot_)foobar(_dot_)com, with
no DKIM
headers. The mail is sent somewhere that carefully checks all DKIM
signatures. The policy of subdomain.foobar.com is checked, and no
policy is found, therefore mail is sent through regular spam filters, and
accepted.
If you look at one of the initial SSP proposals,
draft-allman-dkim-ssp-01, there's actually an upward tree-walk to make
sure that an attacker isn't inserting a subdomain (or multiple levels of
them) to circumvent signing practices published at a higher level. If
the verifier walks up 5 levels and doesn't either get to the root or to
a signing policy of some sort, then it's suspicious. The constraint on
the number of levels was chosen to blunt make-work attacks on the verifier.
The next revision of that draft, although not finalized, will probably
do things differently. It will check both for the existence of the SSP
record and for the existence of the domain. If the domain exists but
the SSP record doesn't, then it will search up only one level.
The real problem here is that conceptually, policy should always always
always come from the top. If the top-level policy wants to say that
sub-domains can set their own policy, that's fine, but it should be part
of the policy structure. If a top-level policy wants to say that
sub-domains can NOT set their own policy, DKIM should give them that
power - without dictating how freely they manage administration of
subdomain DNS.
That's not really the way that things work with DNS. Anyone that
administers a subdomain can publish an MX record and receive mail for
that subdomain. There isn't any parent-domain restriction that can be
imposed. Similarly, we aren't imposing parent-domain restrictions on
the SSP that a subdomain can publish.
To accomplish this, the policy should include information on overriding:
override-depth=0 (no overriding)
override-depth=1 (sub-domains only, not sub-sub-domains)
override-list=baz,cows,a.b.c (short list of subdomains that can override)
Note that for short lists, you can put in something like a.b.c, but you
don't have to. You could just put in "a", and then let a's overriding
policy include "b", and b could include "c", allowing for complex
overriding without massive exception lists. On the other hand, if
a.b.c can be fit into the policy at the top, then two levels of policy
checking can be skipped, and you can directly check the policy of
a.b.c.foobar.com.
So when you get mail from host.foobar.com, or even from
a.b.c.d.e.f.......z.foobar.com, you should check for a policy at
foobar.com.
If the policy says no overrides, then whatever policy you find, you're
done, and you don't have to look up any more. If there's no policy,
you assume a default of override-depth=1 (or at most 2), and walk down
one step. If no policy is found there, then you're done, and policy
is null.
This is an interesting and flexible idea, but somewhat outside our
threat envelope. Subdomains can publish DKIM keys. Why shouldn't they
always be able to publish SSP?
The default depth prevents spammers from coming up with bogus, many-dotted
host names that would be slow to process. And it wouldn't be too onerous
because it gives managers lower down the tree two (or three) different
levels above that it can go to try to get an override policy put in place for
them to implement DKIM on their own.
Using this method, we get:
* Large organizations can set a firm policy that can not be overridden
thru negligence, malice, or mistakes, and that results in very fast
policy lookup.
* Large incompetent organizations have one or two levels of recourse below
the top for sub-managers to implement DKIM, where the top level has failed
to do so.
* Large competent organizations can also be highly flexible in managing
the policies of subdomains, trusting only those sub-domains worthy of
trust.
Even if a default override-depth of 2 were chosen, then there would be
at most three DNS lookups for domains with no policy, which is the same
as the current proposal.
Thanks for your thoughts. Hope what I said makes sense.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html