----- Original Message -----
From: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
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