Dave Crocker wrote:
Jim,
Jim Fenton wrote:
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).
I thought we had agreed that the one-level-up hack (or one-level-down,
depending on your spec) specified in the document was intended as an
administrative convenience, rather than as a discrete security mechanism.
At this point in the discussion I'm describing what the domain
administrator wants to accomplish, not how they're accomplishing it.
This is a requirements statement.
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.
Right. But it won't cover the cases in which the site has a
multi-level domain naming substructure, as many organizations do.
This is why the one-level mechanism really is only about saving the
administrator from creating a set of records.
Please read on, the discussion of multi-level domains comes later...
(Has there been a discussion about the trade-off between saving some
administrators this effort, versus the transactional overhead of
having every receiving host do extra queries, so see whether there is
a record one-level up?)
I don't know, but it seems like an apples-and-oranges comparison to me.
The former is either human effort or the ability of existing tools to
support publication of records. The latter is protocol overhead.
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 the check-for NXDomain is intended to cover those cases where the
site has set -all and has indeed provided ADSP records (directly or
implicitly) for all domain names it controls?
Not sure I understand the question. The NXDOMAIN check does not cover
subdomains that exist. These need explicit publication of ADSP records
as required by section 4.2. The NXDOMAIN check covers names (subdomains
and terminal nodes) that do not exist (i.e., there is no entry in the
DNS, under any RR type, corresponding to that name).
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).
I do not understand this sentence. It parses as a sentence, but I not
see the semantic sense in it. Please clarify.
Subdomains: If www.eng.example.com exists, then eng.example.com is a
subdomain.
Terminal nodes: ns.example.com, www.example.com (typically, but not
exclusively nostnames) are terminal nodes.
The one-level-up query relieves the domain from the need to publish ADSP
records for ns.example.com and www.example.com, but it does not relieve
the domain from the need to publish an ADSP record for eng.example.com.
The first part of the sentence seems to contradict statements you made
earlier about the mechanism, when pressed on its relevance.
Could be. I acknowledge that my thinking has evolved over time.
This
greatly reduces the burden of publication required to get complete
ADSP coverage.
And I do not see how your sentence, here, is different from "relieving
domains from publishing [some] ADSP records for sub-domains. That's
what I mean by administrative convenience.
"Administrative convenience" is largely accurate. The one-level-up
query helps with ADSP deployment by relieving the domain administrator
of the need to publish an ADSP record along with every A record in the
domain. This is both a convenience (in the case of manually-managed
domains) and a tooling issue (for domains with large numbers of
hostnames, including those that may be autopopulated from DHCP address
pools and such).
Conversely, if it is sufficiently inconvenient or impractical for a
domain to publish these records (absent the one-level-up query), domains
won't do it, and it becomes a security issue (to the extent that ADSP is
a security mechanism at all) because it will be possible for attackers
to use those hostnames to avoid whatever recipients do with unsigned
mail when ADSP stronger than "unknown" is published.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html