Subject: [ietf-dkim] NEW ISSUE: Applying SSP to sub-domains does not work

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:54:32 -0800

>>     s  The signing practices apply only to the named domain, and not
>>          to subdomains.
> 
> So this is intended to overcome the problem of not being able to use wildcards?
> 
> What is the query behavior that validators need to use, to discover this
> record, when they start with a message having a deeply-nested From field
> domain name? 

To the extent that the above is not sufficiently clear:

There is not way to properly enforce or even discover the semantics of this 
flag, in the general case of sub-domains.  This option needs to removed or be 
specified in a way that works.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 08:08:01 +0100

Dave Crocker wrote:

> There is not way to properly enforce or even discover the semantics 
> of this flag, in the general case of sub-domains.  This option needs
> to removed or be specified in a way that works.

I think it's the op=nosub idea for A.B.C.example, if A has no policy,
then B's policy needs a way to say that the "general" policy is at C.

This op=nosub was a variant of the CSV left-to-right algorithm for an
old SPF draft that still had "zone cuts".

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Dec 2007 00:16:40 -0800

Dave Crocker wrote:
> There is not way to properly enforce or even discover the semantics of
> this flag, in the general case of sub-domains.  This option needs to
> removed or be specified in a way that works.

This does not address the wildcard issue.

The parent-domain checking is done primarily to ease SSP deployment for
domains having large numbers of hostnames.  Without this feature, a
domain needs to publish an SSP record for every label in the domain, so
that it's not possible to trivially bypass SSP by using a hostname as
the domain part of a From address.  Otherwise, an attacker could use a
>From address like [email-masked] and [email-masked] where
www and zeus are hostnames within the domain.  The DNS folks say there's
no problem with having a lot of records in a domain or zone, so it's
just a practical matter of getting them published.

This mechanism does not address deeply-nested From domains.  Either such
domains really do exist (in which case they need SSP records), or they
do not (in which case the domain query will return NXDOMAIN), or there's
a wildcard, in which case a deeply-nested address will probably just
look non-Suspicious.

The "s" flag just keeps the policy from "bleeding down" to subdomains
(and hostnames, etc.) in those cases where it is not desired.  It's
discovered when the parent SSP record is retrieved; if it contains the
"s" flag, the parent record is ignored.

This issue is also being tracked as issue #1402 that I opened a year ago.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Dec 2007 08:11:04 -0800

> This does not address the wildcard issue.

(Has the s flag been vetted with DNS experts?)

> the domain part of a From address. 

Since a sufficiently nested sub-domain will still permit bypassing SSP, the s 
flag gives the appearance of extra protection but not the fact of it.

> a wildcard, in which case a deeply-nested address will probably just

If this is acceptable for deeply nested domains, why isn't it acceptable for 
shallow-nested ones?

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 17 Dec 2007 14:11:41 -0800

> (Has the s flag been vetted with DNS experts?)

Not specifically.  The s flag doesn't affect the number or nature of DNS
queries at all.  All it does is determine whether a parent domain SSP
record, once retrieved, should apply to a child domain.  It is analogous
to (but not the same as) the "s" flag in RFC 4871 (section 3.6.1, under
the "t" tag).

The s flag, like its counterpart in RFC 4871, can be used to limit the
effect of the record in which it is contained to only the specific
domain in which it occurs.  It was created to allow example.com to
publish SSP without necessarily having it apply to sub.example.com.  In
other words, it allows the subdomains to take the default "unknown"
practices without actually publishing a record.  I am personally
ambivalent as to whether or not it is needed.
> Since a sufficiently nested sub-domain will still permit bypassing
> SSP, the s flag gives the appearance of extra protection but not the
> fact of it.

Presumably you mean the lack of "s" flag, since that flag constrains the
effect of an SSP record not to affect subdomains.  In any case, section
4.2 of the draft is quite specific about what records need to obtain, in
your words, "protection".

Perhaps you are referring to the one-level upward lookup for an SSP
record.  More on that below.
> If this is acceptable for deeply nested domains, why isn't it
> acceptable for shallow-nested ones?

It isn't clear which "this" you mean, but I'll assume you mean, "Why
doesn't SSP address deeply-nested From domains, but has a special
mechanism for shallow nested ones?"

As has been much discussed, hostnames can be legally used as domain
names in email because of the fallback to do an A record lookup if the
MX fails.  Many domains have thousands of hosts, and therefore if one
wanted to publish SSP for each one (e.g., www.example.com, so that mail
from [email-masked] would be subject to SSP other than "unknown"),
it would be necessary to publish an SSP record alongside each A record
in the domain.  I'm told there's not a scaling problem with this, but
I'm not aware of tools that would help one do this.  It's not good if
SSP is vulnerable to this sort of attack until new tools are widely
deployed.

The one-level upward search is a compromise.  Earlier versions of the
SSP specification contained multiple levels of upward search, and there
seemed to be wide consensus that "tree walking" of this sort is
harmful.  Instead, the current draft limits this to one level (a maximum
of one extra DNS query).  The rationale for this is that single level
names are quite common, but multiple level names within a zone (e.g.,
foo.bar.example.com published within the example.com zone and not
bar.example.com) are considerably less commonplace.  So the requirement
is that foo.bar will need its own SSP record, but www will not. 
Subdomains (as distinct from the isolated foo.bar label) should have
their own SSP records regardless.

The idea here is to solve 90%+ of the problem of having to publish LOTS
of SSP records and without increasing the load on DNS significantly.

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Dec 2007 08:40:33 +0100

> of SSP records and without increasing the load on DNS significantly.

Right.  At least for some time to come the administrative burden of
having to add an SSP record for every OTHER record would be exorbitant
and error prone even if it had no significant impact on memory or CPU
utilization.  We need some way to avoid that without at the same time
opening massive attack vectors.  At SOME point DNS management systems
could simply replicate a default SSP record when they create domains,
but we are nowhere near that point.  Having a standard to code to would
help...

Eliot