[ietf-dkim] 1193 considered harmful
pbaker at verisign.com
Wed Mar 22 11:57:57 PST 2006
I agree, we have already agreed to introduce a new cannonicalization: the
slippery slope argument is not operative.
The slippery slope argument is difficult to distinguish from 'I don't have a
real case to make against this change so I will make an unanswerable
objection based on the possibility of unforseen consequences'. The more
relevant question is whether this commits us to a change that breaks
backwards compatibility, it does not as we have already made this
We have a good deployed base and I don't want to see that trodden on without
cause. But the consequences of minor treading are not serious. Verifiers are
part of anti-spam infrastructure that is aggressively upgraded at this point
in time. I think that we can manage a transition without creating a long
term maintenance issue. We are not talking about a major impact on already
written code, it is a detail change that does not require major
I would have serious issues if we had a major deployed base of verifiers.
I very much prefer the separate hash approach for several reasons:
* It is easier to debug deployments.
Unintended modificaiton of the head and body can be distinguished.
If there are multiple signatures it is possible to see who probably
* In a reporting environment the sender can adapt the canonicalization
If mail sent to vmail with cannonicalization A is repeatedly
body validation failures try canonicalization B
* It allows for a more flexible software architecture
Message digests frequently calculated for other purposes can be
Mailing list signers only need to digest the body once.
* The costs are marginal, at most an extra digest cycle.
With this particular change DKIM would be exactly isomorphic to
Authenticater Sender, the VeriSign domain keyed signed email proposal
(leaving aside the ability to link to certs which is an option/extension
issue). I believe that with this change DKIM has reached a local minima, I
am not aware of other likely slippage.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5986 bytes
Desc: not available
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20060322/0cdcd6b5/smime.bin
More information about the ietf-dkim