Dave Crocker wrote:
Just to make sure we are on the same page about the hierarchy trick in the
spec:
The one-level-up hack might be useful for saving some administration, but
it
does not provide meaningful "protection", since all an attacker has to do is
use
a level down.
I'm not entirely clear on what you mean by "a level down", but let me
try to take a stab at it.
Suppose example.com has "all" signing practices that it wants to extend
to itself and everything under it (at multiple levels).
Suppose a message comes with an author address of
user(_at_)ns(_dot_)example(_dot_)com
(hostname ns.example.com exists). The one-level-up query will apply the
ADSP for example.com.
Suppose a message comes with an author address of
user(_at_)foo(_dot_)example(_dot_)com
(hostname foo.example.com does not exist). The step-2 query will result
in an NXDOMAIN, so the ADSP result will be "the domain does not exist".
"Domain" in this context means the right-hand-side of the address as the
term is used in RFC 2821.
So now the attacker uses a level down...
Suppose a message comes with an author address of
user(_at_)foo(_dot_)bar(_dot_)example(_dot_)com (hostname foo.bar.example.com
does not exist).
Again, the step-2 query results in an NXDOMAIN, and ADSP says "the
domain does not exist".
Suppose a message comes with an author address of
user(_at_)www(_dot_)eng(_dot_)example(_dot_)com (hostname www.eng.example.com
exists). In this
case, the one-level-up query does not reach the example.com ADSP
record. For full coverage, there MUST be an ADSP record for
eng.example.com, as required by section 4.2 paragraph 2.
The point of the one-level-up query was not to relieve domains from
publishing ADSP records for subdomains, but rather for hostnames and
other terminal nodes ("terminal node" as used in RFC 2136). This
greatly reduces the burden of publication required to get complete ADSP
coverage. As I mentioned in another message, we do need to sharpen the
language to not use the term "subdomain", which might imply multi-level
coverage.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html