[ietf-dkim] New Issue: Applicability of SSP to subdomains
ietf-dkim at kitterman.com
Sat Dec 9 08:24:58 PST 2006
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.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.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.b.c.d.example.com.
> >> 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
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
Going back to Jim's slides that he reference earlier, I think there is a
requirements trade between slides 3 and 4:
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
Back to requirements...
It should explicitly NOT be a requirement for SSP to cover non-existant
SSP records MUST be wildcardable for the domains the relate to.
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....
More information about the ietf-dkim