On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote:
TXT RR tags
h: Acceptable hash algorithms
If a site wanted to revoke instantly any signature previously
generated with rsa-craphash, couldn't it just revoke its old keys
and generate new keys, and begin signing with rsa-goodhash?
What's the advantage of having a mechanism to disallow future
verifications using a particular hash without just changing the keys
you're using? Both times you have to touch DNS and reconfigure your
signers, so I don't see that leaving "h=" in there gives you
anything you can't already do some other way.
Disagree. This feature is about better informing recipients as to the
status of the signature.
A DKIM signature may contain algorithms unimplemented by all
receivers. The algorithm may replace those that have become
vulnerable. Who knows, since would be speculating about future events
in the face of massive bot-nets. Until receivers are upgraded during
the transition, it would be possible for the DKIM protocol to
establish which message signatures are unverifiable, from those that
are really invalid. Unverifiable would be confirmed when the signing
domain's key matches against the DKIM signatures header. Whenever the
domain's key's assertion is found not to match against the DKIM
signature header, this message could be rejected as an attempt to
spoof an unverifiable signature.
While a problem today, but this might be in the future. There is
nothing gained by removing it. This feature will need to remain
documented, where it just might prove its value some time in the future.
By allowing it to be possible to defend against spoofed unverifiable
signatures, users will remain better able to employ ancillary services
that could bolster the abilities of the receiving MTA. This key
related feature would help minimize the amount of confusion that might
be generated during algorithm transitions that might extend over long
periods of time. Otherwise, bad actors will exploit this situation by
spoofing a flood of unverifiable signatures. Without this feature,
the situation would be more generally known as the "invalid" signature
problem, where some messages would be unverifiable, but most would be
spoofs of unverifiable messages, and everyone wondering what to make
of the mess.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html