ietf-dkim
[Top] [All Lists]

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

2009-06-04 18:42:47
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote:

 TXT RR tags

   h: Acceptable hash algorithms

The spec needs to define the supported set of hash algorithms.  
There
may be some value in a signer being able to state that they're  
using
an algorithm that isn't supported, perhaps.

But unless there is a viable attack such that an attacker can  
craft a
message that validates correctly against the domain owner public  
key
using a hash supported by the spec (sha1 or sha256), without access
to the domain owners private key, then there's no need for this  
to be in
the TXT record.

I agree that there's no need for that to be in a TXT record.

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?

Yes, it is a design feature of DKIM that an operational crypto error  
can be instantly "revoked" by merely yanking the keys from DNS (modulo  
cache timeouts etc). The only thing I would correct in your statement  
is the word "revoke." DKIM bypasses the very notion of revocation by  
being key-centric.



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.

None.

        Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFKKEz3sTedWZOD3gYRAnSXAJ41g5EDKKX4ZNCHe4hSFJzuRCtl7gCgr1dg
uyXYARgVPEsA2kwnagYUhVY=
=zPOv
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html