On Jun 13, 2009, at 4:51 AM, Dave CROCKER wrote:
Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
Okay, I would like to keep what we have, removing pieces is not a
good idea, people don't have to use the tags if they don't want to
and we MAY have a need for them in the future.
There is an infinite array of features that we may have need for in
the future. So that's not an encouraging line of argument for
retaining any particular feature.
During early DKIM development about three years ago, I argued against
adoption of user restricted DKIM keys. Several individuals with a
security background dismissed the concern by stating that a key MUST
allow user restrictions as an essential feature, especially for remote
signing. My concern at that time was how this feature might be
abused, such as those at Yahoo! suggesting they could publishing
millions of individual's DKIM keys in DNS. No doubt they could.
Features carry costs.
Modifying DKIM also carries a cost. The time to argue against these
features has passed.
Perhaps you missed my earlier note, which touches on the significant
costs of retaining unused features:
The definitions of unused features seem constrained to a subset of
providers.
When influential providers want to develop different signing
mechanisms, there is nothing preventing them. In order to minimize
the complexities in describing what a valid DKIM signature means, not
changing how a valid DKIM signature is defined better preserves both
the security and the clarity of DKIM signatures. Changing DKIM's
definition two years after its introduction opens more security issues
than are resolved.
Perhaps some providers are upset that some DKIM features allow
original messages to be isolated from injected ads, for example. As
it happens, some of these ads have caused security breaches due to
various cross-site scripting and iFRAME related issues. It seems the
features being declared "unused" also enable the isolation of injected
ads. Often such injected content damages HTML page presentation when
carried as an email message. Isolation of this information can
ensure page annotations better preserve the intended presentation,
and ensure the source of injected information is not confused with
that of the sender.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html