On Fri, 2005-03-25 at 17:35, Radu Hociung wrote:
And since the mask modifier appears to have so much benefit for so
little cost and risk:
- the mask modifier should be added. Andy is the only one with serious
objections, so once we've cleared up what's best, we'll know if
we should add the m= modifier, or just use the exists: statement.
I have absolutely zero objections to the mask modifier, it is most
definitely a good addition. I support its addition.
What I have objections to is the assumption that things will magically
be better just because it is added to the spec, as if it suddenly fixes
all the problems that have been proposed that it does fix.
Adding the mask modifier to the records does not do anything for those
SPF evaluators who treat modifiers as optional (because they can be) --
the exact same DNS load and amplification issues exist because, while
the syntax is backward compatible because it's a modifier, the modifier
needs to be honored in order to see the intended benefit. So rather
than it being one party's problem to resolve (the publisher, by making a
less complex record that causes less load), it is now a two party
problem, the publisher needs to put the mask in the record, and the
recipient needs to update their SPF checker.
If SPF-Doom attacks before there is 100% deployed support for the mask
modifier, people are still more likely to just disable querying of TXT
records. Recipients do the work of upgrading their SPF checker but are
still vulnerable because publishers are not using the mask modifier.
Publishers add the mask, but are still vulnerable to increased DNS load
because recipients have not all upgraded. One of your examples, Radu,
had zombies searching for SPF enabled domains to target indirect attacks
against. This same issue applies if zombies were to search for
expensive SPF records that didn't have masks. Adding things increases
the changes that the transition will more painful.
I get the impression that masking is considered some holy grail --
masking does fix a number of things, but it is still a long road ahead,
a road filled with providing education to those who might (or have) come
under attack as to what needs to change and why it's not SPF's fault
(but that still doesn't keep people from blaming SPF). Adding anything
new does not short circuit any of the work that needs to be done.
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>