On Saturday 09 December 2006 07:02, Michael Thomas wrote:
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.
From a requirements perspective, I think providing policy for non-existent
domains is explicitly NOT a requirement. For a domain to be covered by SSP,
it MUST exist. I like Graham Murray's definition of exists.
Once you limit yourself to extant domains for SSP, then I think that (with the
limited exception of domains that exist solely due to DNS wildcards) there is
no requirement to deal with subdomains. An explicit SSP can be published for
every domain.
So, then the question becomes are wildcards worth the trouble? I'd say not,
but they are part of the existing infrastructure, an so I imagine they can't
be ignored.
Going back to Jim's slides that he reference earlier, I think there is a
requirements trade between slides 3 and 4:
http://www3.ietf.org/proceedings/06nov/slides/dkim-3.pdf
Slide 3 describes using a new RR type for SSP. Once you use a new RR type at
the domain level (not as an underscored domain name) then as I understand it,
SSP records could be wildcarded. So, if you have the ability to wildcard SSP
records, (given SSP only covers domains that exist) then there is no
requirement for hunting for parent/sub domains. The problem in Slide 4 is, I
think resolved (NXDOMAIN is enough of an answer).
Slide 4 describes a problem is the SSP record cannot be wildcarded which, I
think, drove Jim's original question here about hunting for
parent/sub-domains.
Back to requirements...
It should explicitly NOT be a requirement for SSP to cover non-existant
domains.
Either:
SSP records MUST be wildcardable for the domains the relate to.
or
The search for SSP records much include looking to parent domains.
I don't think we need to do both.
Perhaps for now, both concepts could be encapsulated in a higher level
requirement that says that SSP records must be fetchable for domains that
only exist due to DNS wildcards and either of those approaches is a design
for meeting those requirements.
I guess there's a reason you could read my response both ways....
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html