[ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM
and (eventual) IETF DKIM
earl at earlhood.com
Tue Oct 18 09:08:58 PDT 2005
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.
More information about the ietf-dkim