----- Original Message ----- From: "Mark Delany" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, July 25, 2006 1:37 AM Subject: Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method
> This is a replay issue: > > o I get a verified email from paypal that has MIME attachments. > o I strip out the CR/LF characters to create the second form. > o I re-inject that mail into the system to some unsuspecting > bunny who has whitelisted paypal. > o Since STRIP will still verify such email, the bunny bypasses their > protective layer because they trust paypal. Mark, I don't see it. Wouldn't a high value domain such as PAYPAL hashing include From: and To: ? If so, that cant change if the signature is to survive this redirection. At best, all I see done is a mail redirection with nothing removed but CR/LF characters from the body. What is gained by the bad actor? Besides, if the bunny is white listing paypal, does it matter what is sent? Is DKIM expected? This all goes back to SSP related protections as well. If I really wanted to fake out the bunny, I would send it a message without DKIM markings. > Really? That's quite the generalization. Besides which, there is a > delimiter as the example removes one, not all delims. The case is > simply that the Content-Type: is now invalid. What can you say with > 100% certainty about how all MIME parsers will deal with that? With 100% certainly I do not expect any of my mail software engineering peers to be correcting or even trying to correct or de-join or split MIME headers that we joined by some mutation. The point is, for this particular scenario, its not a consideration how they will deal with it but with 100% certainty, there will be problems and in most cases, the problems are typically presented with customer compliants - "Hey, this message is not displaying correctly." At which point, you may investigate and you might see that it bad line that no one is expected to reasonably understand or deal with. We do what we reasonbly can to deal with it for the customer sake, but you can only go so far. No one should expect anyone to be dealing with 'bad formats." They might do so, but thats besides the point. > Right. But a bad guy can modify the original content and it will still > verify with STRIP. This isn't about good-guys correcting, it's about > bad-guys modifying such things as general service notices from paypal > and replying them back to bunnies. Ok. But nothing as been done to address that. Unless I missing something, we are talking about increasing the survivability of the signature in the current infrastructure where we are wasting alot of time discussing dead horse issues regarding 822/2822 mutations. If there is a security issue related to it that is more than what we have now, I would like to see it. Not saying there isn't one. I just have yet to see it. If its there, would it be any worst than what we have now? What we don't have now is reliability of the signature hashing algorithm. Well, anyway, thanks for comments. :-) -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
