Scott Kitterman wrote:
On Fri, 08 Dec 2006 15:23:58 -0800 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Eliot Lear wrote:
Jim,
I'm not sure I fully understand the threat. If an attacker is
attacking from mail.example.com, then mail.example.com must have been
delegated to first in example.com. Otherwise, there would be no
lookup for an SSP record in mail.example.com, right?
I had thought the concern was the wildcard concern about how much
trust is afforded between superior and inferior domains. In that
case, I answer, "you pays your money you takes your chances". Don't
like a particular superior? Find another. If you can't for policy
reasons, then that's not a technical problem.
What do I have wrong?
It's fairly simple. Let's say I have a policy record setup for:
_policy._domainkey.example.com: "policy=I-sign-everything;"
Then if there's unsigned mail for foo(_at_)example(_dot_)com, I look it up
at example.com, I see that unsigned mail is bogus, life is good.
So attacker now gets smarter and sends as
foo(_at_)a(_dot_)b(_dot_)c(_dot_)d(_dot_)example(_dot_)com(_dot_)
Is there a policy record there? No. Can I populate every possible
subdomain there? Not with DNS wildcards, therefore no. Uh-oh.
Well, I guess my question would be does a.b.c.d.example.com exist? If not
I think perhaps I don't want their mail in any case.
If SSP limits itself to domains that exist, then doesn't that simplify
things.
Define "exists". That there's an A record there? That it's pingable? What?
That's pretty much the root of this problem -- you need to have coverage
and it needs to conform more or less to what's legitimately deployed. I
for one would like to see more creative suggestions in the solution realm
because nothing I've seen seems especially satisfactory and strikes me as
meeting the conform test at the same time.
But the main question here is really for requirements: should defining
some method be a requirement. I can read your response both ways.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html