On 10/07/2010 05:01 PM, John R. Levine wrote: >>> I'd say that it would be better to just say that if you sign a >>> non-compliant 5322 message that its verification is undefined, >>> and move on. That at least matches reality, and hasn't hurt >>> anything that I'm aware of. > > Except that's not the situation we have here. > > a) Author creates a 100% compliant message > > b) Signer signs 100% compliant message > > c) Bad guy adds an extra header, making it non-compliant, and sends it to > someone > > d) Receiver receives it and, uh, well, what? > > Nobody has signed a non-compliant message, so while there is nothing wrong > with Mike's advice, it completely misses the point.
You're right, it does miss the point. What I'm trying to get my head around is whether this is a real problem in the real world. Any reasonable spam filter would notice evil double From:'s in a New York minute, so I can't get particularly worked up about this being some sort of existential threat. Can someone come up with a scenario where this really could be evil and isn't trivially fixed by... making spam filters insist that they're really receiving valid 5322 as one of their rules? Mike, I only have vague recollection of the h= trick anymore... > > As far as I can tell, this problem, detecting header changes, is a > security problem that has never come up before. PGP, S/MIME, and PEM only > protect the body, in some cases by wrapping the entire message as a > message/rfc822 MIME body part and signing that. RFC 2822 and its > predecessors tell you what is a valid message, but say approximately > nothing about invalid messages other than a few historically motivated > notes like bare linefeeds really are invalid. I think I can safely say > that there is no chance at all that Pete Resnick et al. would agree to > change 2822bis to fix holes in DKIM. > > I'm scratching my head to see if there is any advice we can offer to make > signing and verification more robust while not changing the behavior of > existing code for normal (for some definition of normal messages). > > A) You have to sign either all occurences of a header or none of them, and > a message with some but not all occurences signed fails verification. This > is probably too strong, although I doubt that there are many places in > practice where it would matter. > > B) Same as A, but limited to an enumerated set of headers that are > supposed to occur only once. > > c) Same as B, but tell signers to use the h= trick to make verification > fail if extra headers show up. > > R's, > John > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
