On Tue, Jul 25, 2006 at 01:02:05AM -0400, Hector Santos allegedly wrote: > > For example: > > > > --pWyiEgJYm5f9v55/ > > Content-Type: image/jpeg > > Content-Transfer-Encoding: base64 > > > > can get turned into this: > > > > --pWyiEgJYm5f9v55/ > > Content-Type: image/jpegContent-Transfer-Encoding: base64 > > > > Is that a problem? Probably not, but it makes me nervous because I > > can't assess how UAs will react and I can't predict future MIME > > headers. > > Not sure I follow. The canoniculation should be transparent for hashing > purposes. It should not be for correcting feeds.
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. > If such content was change to the above, you would be able to assest with > 100% certainty all MIME processors (including our own) will fail since there > is no delimiter. 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? > All MIME processors are not going be able to parse/read > this anymore. Put another way, no would should expect the MIME processor, > whether it was a UA or some other middle waire mail processor, to be able to > parse the above. There has to be atleast 1 delimiter. That is my point. Code is buggy. DKIM verified mail from a trusted domain will get through to a softer under-belly so a canonicalization has to ask the question: if I allow modifications that get through a softer underbelly what harm can I cause? > The suggestion I am making removes the idea CR/LF alterations have taken > place from the DKIM hashing process. The becomes an independent feed > concept because the canonicalization is internal. There is no > consideration for "correcting" a feed for other systems. 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. Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
