Subject: [ietf-dkim] Policy Discovery

From: "Thomas A. Fine" <[email-masked]>
Date: Fri, 25 Aug 2006 20:28:27 -0400 (EDT)

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.)

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-masked], 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.

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.

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.

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.

      tom

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 22:26:28 -0700

> quite a bit, but not exhaustively.  If I've missed something obvious,
Welcome, Tom.  No smack-down will be needed. :-)

> policy is found, therefore mail is sent through regular spam filters, and
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.

> power - without dictating how freely they manage administration of
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.
> one step.  If no policy is found there, then you're done, and policy
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?
> at most three DNS lookups for domains with no policy, which is the same
Thanks for your thoughts.  Hope what I said makes sense.

-Jim

---

From: "Thomas A. Fine" <[email-masked]>
Date: Sat, 26 Aug 2006 03:15:42 -0400 (EDT)

>the SSP record doesn't, then it will search up only one level.

And if nothing is found in those two levels, that's a way for spammers to
forge spam.

DKIM provides protection for a domain, as well as assurance to recipients.
If BigU.edu wants to have a global policy that it's email is all protected,
this shouldn't be screwed up by incompetent or disgruntled underlings three
layers down.  It shouldn't be screwed up by unpredictable wildcard matching
in DNS servers.  It shouldn't require that every single host in BigU.edu
have a policy attached to it, given that in a BigU.edu environment with
30,000 hosts, this is nearly impossible to pull off.

>the SSP that a subdomain can publish.

But an MX record is a description of infrastructure, not policy.
The MX and the policy can both be stored and distributed in the
same way, via DNS, but there's no reason to require that they be
used in the same way.  And note that I'm not imposing any restrictions
on what's published either, only on how the information is honored.

The fact that anyone who admins a subdomain can publish what they
want is EXACTLY why policy should NOT be examined bottom-up.  It
makes global policy massively more difficult to implement, and in the
long run, global policy is what most big sites are going to migrate
towards.  My approach would make it easier (or simply possible)
to protect an entire domain, without making it any harder to provide
flexibility to subdomains for sites that want that.

>always be able to publish SSP?

Not for us to say.  It's for them to say.  Why should BigU.edu have to
constantly worry about the flawlessness of their entire DNS structure
which is administered by 300 different sysadmins of wildly varying
abilities?

Effectively, anything but a top-down approach is dictating to BigU.edu
that either 1. they can't dictate policy to their own subdomains, or
2. if they want to dictate that policy, they're required to undertake
a massive restructuring of DNS management that's likely to remove most
of the control that the lower level sysadmins currently have.

And DKIM shouldn't force BigU.edu into that corner.

      tom

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 26 Aug 2006 08:44:33 -0400

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "Thomas A. Fine" <[email-masked]>

>> 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?

+1

However, Mr. Fine re-raises a good point that I have on regarding
optimization.  Why should a large company with many sub-domains be force to
create a policy for each sub-domain when one or more can cover many?

I guess perhaps future DNS servers would be able to cater to this better by
merging records for specific query keys.

I punt the DNS gods on this one :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Damon <[email-masked]>
Date: Sun, 27 Aug 2006 05:50:59 -0400

> To: "Thomas A. Fine" <[email-masked]>

Finally! Someone from Harvard proofing some of my previous points...
How do you like them apples? ;-)

Thomas,
 What are your suggestions?

Regards,
Damon