On Mar 18, 2008, at 9:09 AM, Dave Crocker wrote:
Steve Atkins wrote:
Without that check, an unsigned mail from
foo(_at_)bar(_dot_)baz(_dot_)ebay(_dot_)com will
be considered to comply with ASP unless there is an ASP record
for _asp._domainkey.bar.baz.ebay.com or for
_asp._domainkey.baz.ebay.com
...
The domain existence check means that only a defined number of ASP
records need to be published (the number of hostnames you publish
would be an upper bound unless you're using wildcards anywhere else
in your DNS, in which case all bets are off).
(Thanks for Barry for reminding me to review this.)
Steve,
Many apologies, but I am simply not understanding this.
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.
Yup. It adds no new functionality (actually it removes some), but does
make deployment for the record publisher simpler, at the cost of
making deployment for the record publisher less flexible and the
checker more complex and slower.
It doesn't provide for protection of all possible hostnames in a
domain, and using one a level down is one example of that.
With respect to an A record, its presence does tell you that the
name is valid, but it does not tell you anything about ADSP
support. Initially there will be virtually no adoption of ADSP. So
what does finding an A record, but no _adsp record, tell you?
It tells you two things. It tells you that the domain owner is aware
of that hostname, and that they did not choose to publish an _adsp
record that covers it.
If we consider a two step process, where in order for an _adsp[1]
record to match a query it must either be the same, or one level up
the domain hierarchy from the hostname (this is what we have now if we
exclude the existence test - www.example.com will be covered only by a
TXT record for_adsp._domainkey.www.example.com or
_adsp._domainkey.example.com).
A domain owner cannot publish a single _adsp record that covers an
entire domain (example.com and any hostname having .example.com as a
suffix).
Similarly, they cannot publish a finite list of _adsp records that
cover an entire domain. This is true whether or not you consider the
"up one level" hack.
A domain owner cannot conveniently publish an infinite[2] list of
_adsp records.
If a desired functionality is for a domain owner to be able to assert
policy over all hostnames within their domain by publishing a finite
number of _adsp records, then you need an additional step in the
process.
One possibility for that would be to extend the "up one level" hack to
chase up the tree until it reaches the root.
Another possibility, the one in the current draft, is to assert that
the domain owner has a finite number of hostnames in use within their
domain and so can publish a finite number of _adsp records to cover
those hostnames in use (trivially, by a 1:1 correspondence between
_adsp records and hostnames, at worst).
As there will never be a legitimate use of a hostname that may be
checked for an _adsp record that doesn't have any DNS record
corresponding to it[3], asserting an ADSP fail for any case where
there is not a corresponding record in DNS will not cause any
unintended failures, and allows the domain owner to assert policy
across all possible hostnames within their domain. This fails in the
case where the domain owner is using wildcard records for any use
within their domain.
I think what this is uncovering is that adoption of ADSP requires
ensuring ADSP query results for all valid names. In that context,
I guess I can see the benefit of having an A record serve to define
what names are valid.
An A record is not adequate for proof of validity, as there will be
quite legitimate cases where the hostname has an MX record but not an
A record, and we can't assert an ADSP fail there just because there's
no A record. "A or MX" is likely adequate, but "any record" is
certainly adequate, and likely free to check in most cases.
Mumble. This is still feeling a bit squishy to me, although at
least I'm starting to see the possibility of its being useful. (I
think the doc at least is going to have to be much more clear about
its role.)
It's all very squishy. (And part of the squishy is that "but if
there's no A or MX record for the email address then the mail will be
rejected before checking ADSP" is clearly true whether or not an ADSP
spec says so, so adding that step to the spec doesn't actually change
what will be done operationally, but it's needed to make the spec self-
contained and to document the thought process.)
But if there is a desire for a domain owner to be able to assert
policy across all possible hostnames within their domain then you
cannot remove the domain existence check without replacing it with
something else[4]. The approach in the current draft is inexpensive to
check, but does fail spectacularly if there is any use of wildcard
records within the domain. We should document that, probably without
using the phrase "fail spectacularly".
Cheers,
Steve
[1] I'm just following the flow of conversation by using _adsp, don't
consider it a show of support for that phrasing as I'm really agnostic
about the name.
[2] For values of infinite that are in excess of 38^189, if not truly
without bound. Well, you can pretty easily, but not using standard
configurations of bind, powerdns etc, as they don't support
generalized wildcard records.
[3] As the hostname being checked is on the RHS of an email address
there must be an A record or MX record for it, in order for it to
be... operationally relevant, anyway.
[4] Given that the stated purpose of ADSP is to protect email
addresses I believe that replacing both the one level up hack and the
existence check with an explicit check for an MX record for the given
hostname, and returning an ADSP fail for any email sent with a RHS
that has no MX record for it would be a Good Thing, but it would
probably step on too many toes to actually consider as a standard.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html