> For example, say a vulnerability is found in sha1 and a future spec
> defines sha256 as the stronger hash alg. A dutiful signer will
> generate a sha256-based signature and an sha1-based signature.
It may not be obvious to all why this problem shouldn't be addressed
simply by an operator of DKIM verification software making a local
policy decision to ignore signatures which use insecure algorithms.
Perhaps the danger here is wrapped up in some assumptions about that
operator as follows:
a) it assumes that the operator of the verification software is
attending all our conferences and reading our mailing lists so that they
discover current and future vulnerabilities
b) it assumes they will recognize that the verification software they
are using (which was procured from a vendor) is vulnerable (actually
using the compromised algorithm)
c) it assumes they will be using verification software actually capable
of the granularity necessary to select which algorithms to accept and
which to ignore
d) it assumes they will obtain sufficient motivation to take any
corrective action at all
Anyway, just some additional thoughts along these lines.
--
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html