ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms

2009-06-04 18:48:01

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