On Jun 2, 2009, at 3:36 PM, Murray S. Kucherawy wrote:
Without this feature, people may soon find their inbox flooded by
bogus messages indicating the use of new algorithm, that could have
been mitigated extensively by having the key feature.
As opposed to what? What would you expect a verifier or assessor to
do if the hash used to sign was not in the key's approved hash list?
It would be reasonable to assume the lack of a matching algorithm
within the key record would be a strong indication of a spoofed
signature. The duration before new algorithms are universally
supported could be fairly long.
Wouldn't it get delivered anyway, but perhaps with a slightly
different annotation?
It would be preferred to have "Unsupported Signature Algorithm"
reserved for domains that indicate they actually use the unsupported
algorithm. Without the key being able to make this indication, all
such messages might then receive the same indication, or be rejected
where the recipient could have taken steps that check the signature's
validity independently from the non-updated MTA.
I don't see any value here other than disabling verification using a
known-compromised hash algorithm. But even that wouldn't inhibit
delivery, only change annotation.
Huh? This is not about known compromised hash algorithms. This is
about asserting the proper annotation for new algorithms not yet
supported by the receiver.
When a message is received that has the signature:
DKIM-Signature: v=1; a=ecdsa-md6; d=example.com; s=sel; ...
Annotation A "Signature algorithm not supported by receiver" can be
noted when the key record is:
sel._domainkey.example.com. TXT "k=edcsa\;. h=md6\; ...
Annotation B "Signature algorithm not supported by either the sender
or the receiver!" can be noted when the key record is:
sel._domainkey.example.com. TXT "k=rsa\;. h=sha256\; ...
By being able communicate what a sender supports for a specific key
limits the number of domains that might receive the Annotation A
notation or some ambiguous signature failure indication.
When the message receives the annotation: "Signature algorithm not
supported by either the sender or the receiver!" this should cause the
message to be treated with prejudice where users will know that
additional verification steps will prove futile.
Not having this feature will mean users are unable to differentiate
between the Annotation A or Annotation B cases. Being unable to
communication this significant difference allows bad actors to benefit
by the confusion thereby created.
Without this feature being in place, there will be a greater
reluctance to upgrade DKIM algorithms due to the potential for
confusion.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html