Folks,
People have reached a level of saturation and exhaustion on the question of
doing an existence/validity check, to see whether a name is registered [and
intended for email use.]
Over the last couple of days I've been having a private exchange, trying to
lay out the logical underpinnings to the arguments for and against such a
test, stepping through requirements and challenges for this, within the
context of ADSP.
I'm posting a highly edited version of the two sides, here, in the hope that
we can look at details, rather than just reiterating our summary judgements
about how essential or irrelevant the test is.
Since I'm totally biased, I'm not likely to create the "pro" side very well,
so I've tried to use the other participant's statements, and believe my
editing has not altered their intent. Still, if you think I've gotten the
"pro" side wrong, blame me, but also tell me how to fix it.
PRO
---
ADSP is supposed to arm the domain owner with a means of protecting his
*name space* from unauthorized use in an email From: header. ADSP is
supposed to arm the mail receiver with a means of detecting unauthorized
domain use in an email From: header.
The domain owner will publish ADSP records for everything he possibly can.
However, it is impossible for him to publish ADSP records for host names
within his name space which do not exist. It is ridiculous to expect a
domain owner to put an ADSP record everywhere he possibly can while knowing
at the same time that an attacker can completely by-pass this by just
making up an arbitrary host name.
We're saying it's important for the algorithm to distinguish between "No
ADSP due to the domain owner's failure to provide it" and "No ADSP because
the domain is bogus and ADSP couldn't have been provided by anybody."
It's mission-critical to prevent ADSP from complete uselessness through
affixing an arbitrary host value to a domain that otherwise has done
everything ADSP allows to protect itself. Please understand that an
attackers use of "bogus(_at_)DoesNotExist(_dot_)paypal(_dot_)com" *still
reflects badly* on
paypal.com and the domain owner of paypal.com would definitely put a stop
to that if he could.
If an NXDOMAIN check is not performed _THEN_ it becomes trivial for an
attacker to circumvent ADSP.
It's certainly meaningful protection to prevent abuse through use of
arbitrary host names.
CON
---
I suspect a critical issue is the exact meaning of "name space". As used
here, it appears to refer to everything under the 'root' of an owner's
domain. That is, it is meant to cover an entire sub-tree, rather than to a
specific, single, registered string.
For any given (specific) domain name, the owner always has the ability to
register an ADSP record. This protects that specific name. By publishing an
ADSP record the owner says "Every legitimate message with this exact domain
name string in the From: field is signed with this same, exact domain string".
Any use of that name in the From: field without a signature will be detected.
An attacker cannot bypass the direct protection of that specific name. Any
message that does not contain that signature is detected as problematic.
What this means is that direct ADSP registration protects all registered names
that the domain owner has chosen to protect. So, the concern behind the
existence test (NXDomain or the like) is not whether the domain owner chose to
protect any particular name but whether the domain owner is using it.
The existence check sets the goal of protecting unused names under a some
domain name "root".
The "still reflects badly" statement asserts that such unauthorized use of an
unregistered name will hurt the reputation of an organization's "root" domain.
The assumption is that a specific domain name and all of the names under it
will share the same reputation.
This is an eminently intuitive and reasonable concern. If paypal.com has a
reputation, it is certainly reasonable to assume that phisher.paypal.com will
share it. However the real-world impact of such generalization of reputation
will be to defeat one of the major benefits of using domain names:
Differential reputations within a domain.
We *want* different reputations for transactions.paypal.com and
newsletter.paypal.com and corporate.paypal.com. Remember that these names
that are used to sign with DKIM are voluntarily chosen by the signer. If they
use different strings, they intend different assessment. If we assume an
inheritance, tree-based model for reputation, such as with paypal.com, we
eliminate this very useful ability to discriminate among different mail
streams coming from an organization.
This design ability with domain name-based reputation exactly matches the data
we have seen posted to the mailing list about actual reputation usage:
Reputation data for IP Addresses covers ranges, yes. But the statements about
domain name use say they are tied to a specific, complete name, not a string
that is the root of a sub-tree.
In terms of the affirmative, proactive model of DKIM and ADSP, seeking to
protect unregistered names creates is, therefore, wasted overhead.
An existence query might be worthwhile in terms of other concerns and models,
but it has nothing to do with the scope of this working group. Worse, it sets
entirely inaccurate expectations for DKIM and ADSP.
OK... start shooting.
d/
ps. The above does not deal with an important additional test: If there is
to be a test, given that there is a range of established industry practice,
how is this working group to define a particular standard that will appeal to
the industry?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html