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 [EMAIL PROTECTED], 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
