On Jun 1, 2006, at 6:37 PM, Michael Thomas wrote:
Douglas Otis wrote:
A DKIM implementer might also need to include DKIM related security
terms and conditions with private providers in conjunction with
future
or existing services as related to the publishing of DKIM keys and
their
use. This is a new security related element independent of normal
domain delegation obligations.
I have no idea what this means, so I'm virtually certain I'm not
going to do it.
Additional obligations are needed specifically due to the fact that
DKIM currently permits any high level domain to claim authority over
the i= parameter. This consideration vanishes by mandating the
domain assured in the i= parameter must be the same domain as that of
the key. This parity would ensure existing domain delegation
obligations protect the use of the i= parameter. This parity also
resolves the g= problem as well. Without key parity, retirement
rates, key size, private key half handling and i= assertions all
become new concerns to be negotiated by both regulatory bodies and
DKIM implementers when obtaining delegations from private providers.
Think of the receivers...
Increased efforts by the receiver greatly outweigh reduced efforts of
the transmitter. This practical reality works against CNAMES with
selectors, for example. Allowing any number of sub-domains
represented by a single parent domain may force receivers to list
unacceptable sub-domains when the parent signing domain represents
too many legitimate email sources to block. Should the domain allow
MUA signing, the number of sub-domains that might be used becomes
unlimited. At that point, blocking at the key becomes necessary
which also greatly increases the burden on the receiver where
blocking John(_dot_)Doe(_at_)bar would also block John(_dot_)Doe(_at_)foo(_dot_)bar, for
example. Instead of allowing the receiver to base acceptance on the
domain, the receiver is forced to resolve acceptance based upon a
much greater number of keys. This is unrealistic and onerous. Far
more onerous than what would be expected of the transmitter when
requiring validation parity with that of the signing domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html