On Wed, 9 Jan 2008 05:24:44 am Murray S. Kucherawy wrote: > 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.
guess I was hoping a more flexable SHA API existed. > 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. I may play with it and look at the implementation. The self tests should be able to detect failure however I understand your prudence. > > 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". That make sense from a standards ideological point of view. > 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, So my bodylength tag database patch may be useful. > and encourage MLM operators in general to re-sign their mail > after munging Subject: headers and adding footers. > This still involves the verifying party trusting the MLM operator. By delivering it though it could be taken as the originator was verified rather than a trusted third party (MLM operator). Probably just a education of users/admins issue. > Insisting on those, however, may or may not be pragmatic. Producing documentation about DKIM from a MLM operators perspective may alleviate some pragmatism. Other solutions could be providing patches to software like mailman that will reject DKIM email without bodylength tags that it intends to mangle. Maybe modifying the documentation to highlight the risks of subject and body prepend/appending. > >> 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. Haven't looked at them yet. Good to know they exist. Thankyou. > Of course, the question then is "OK, so now what?" whatever it is, lets make it easy and documented for whoever needs to take action. > > 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? Yes I was thinking of a whitelist of MLM operators. For larger volume of server the management of the whitelist could be delegated to the users in some fashion. > 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. Sounds good. Thankyou. I probably should join the list myself though i've got a bit to catch up on. -- Daniel Black -- Proudly a Gentoo Linux User. Gnu-PG/PGP signed and encrypted email preferred http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x76677097 GPG Signature D934 5397 A84A 6366 9687 9EB2 861A 4ABA 7667 7097
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
