On Tue, 8 Jan 2008, Daniel Black wrote: > Is the incremental hash state approach acceptable? I was looking at > ./libdkim/dkim-canon.c and it does seem like a non-trival amount of > effort.
It depends on how the SHA contexts (objects) work. For example, if calling SHA1_Final() on a SHA1 context makes it unusable for further calls to SHA1_Update(), much like fclose() would for a FILE handle, then the only thing you can do is maintain several parallel SHA1 contexts and feed them data separately. That would mean two header hashes (one for the received Subject: header and one for what you think the original is) and N body hashes where you want to try omitting up to (N-1) trailing lines. The SHA API documentation (i.e. the man page) doesn't say whether or not you can safely do this, so it's prudent for me to assume I can't and thus I must err on the expensive side. > If you can determine what the original signed message looked like and it > verified ok can it be considered a pass? There were strong opinions in the DKIM working group in favour of the answer to that being a solid "no". You can use the "z=" tag or other heuristics to determine in an automatic fashion what got munged in transit (MLM or otherwise) but the verifier should still consider it a failure to verify. However the way the RFC is written, such courses of action are not expressly forbidden. The use of "z=" is clearly intended for diagnostic work and not included in pass/fail decisions, but there's nothing indicating doing so actually violates the standard. > "Yes" would certianly make it more useful to admins. Especially to those > that don't want to debug dkim failures every time a user adds themselves > to an email list. Admins may need to think wider to determine if this > would introduce risk in replay attacks by the appending short amounts of > text. I think the more overall correct thing to do is to encourage people who are concerned their mail might be munged by appended footers to sign with the "l=" tag, and encourage MLM operators in general to re-sign their mail after munging Subject: headers and adding footers. Insisting on those, however, may or may not be pragmatic. >> This is to some extent what the "z=" tag is for. > > Useful for debugging a failure with the assumed cooperation of the > sender in adding the "z=" flag. Not sure any admin would want to be > debugging for email list traffic for DKIM failures considering its a > known risk in the standard. dkim-filter has tools which make use of "z=" if present to highlight what got changed in transit, so the admin does get some assistance from us there. Of course, the question then is "OK, so now what?" > This would make sence on a small volume server where you add a signature > now and then for emailing lists that you choose to trust. A large volume > server would require the user to self manage a whitelist of signatures > for themselves which isn't impossible either. Sorry, I'm missing what you're saying here. A whitelist of signatures? Can you provide an example? These are all interesting questions. I think I'll summarize them and bring them up on the DKIM working group list for some more dialog and suggestions. -MSK ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
