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
