On October 18, 2005 at 05:14, Mark Delany wrote:
If a signer feels vulnerable to exploitation, they will only use the
safest signature mechanism available. Alternatively, if the signer is
more interested in compatibility they might choose a deployment that
maximizes successful verification. I expect that high value domains
are in the former category while the vast majority of low value
domains are in the latter category.
It appears that a primary concern of mail senders is to make sure the
mail send out gets delivered, especially for businesses communicating
to customers. This behavior raises a security problem since such
senders will go with policies that lean towards delivery versus
potential security threats. A clear example is the lax SPF rules
many senders employ to avoid out-right rejection of mail or minimizing
the chance their messages will be put in a bucket ("spam folder")
that recipients generally ignore.
With legacy DK/DKIM, this behavior will probably not change. Senders
will employ legacy schemes if they know recipients are still using
it versus any newer more secure schemes.
Therefore, even though it is impossible to make something completely
secure, our initial efforts should be as good as possible and not
necessarily hindered by compatibility concerns (of course, each
problem is dealt with on a case-by-case basis).
In effect this is the same issue that will arise when a future flaw is
discovered in the latest, greatest cryptographic algorithm. Signers
will need to decide what algorithmic choice to make as a consequence
and the specification needs to allow them to express those choices.
Agreed. But senders tend to lean towards delivery at all costs,
despite the risks. Therefore, we cannot assume that newer versions
of DKIM will be readily adopted in a timely and efficient manner.
So, all we need to do in the specification is ensure these choices are
possible, then we can let signers manage their own risk themselves.
Agreed. We must also realize that future versions of DKIM may raise
incompatibilities from earlier versions to address security concerns
or future requirements, making versions identification important.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org