Pete Resnick wrote: > I am perfectly happy with Murray's original (and now, revised) text. > (Nits still being discussed are entirely up to the WG.) I am not happy > with Charles's text. Particularly: > > On 7/7/11 5:08 AM, Charles Lindsey wrote: > >> Recall that, when multiple instances of a given header field are >> present, they are signed starting with the last one and working >> upwards (section 5.4.2). This DKIM feature can be deployed to mount a >> variety of attacks against the email system. In some, the attacker is >> also the signer, signing the second of some duplicated field on >> behalf of his own domain, whilst hoping that some lenient MUA will >> display only the first. In others, a genuine signature from the >> domain under attack is obtained by legitimate means, but extra header >> fields are then added, either by interception or by replay. >> > > It seems like this text is tailor-made to obfuscate who is doing the > attacking and who is being attacked. It's this distinction that I think > is the most important to make, and the above text simply does not > clarify; it muddies the waters. DKIM can only be "deployed to mount a > variety of attacks" if the recipient has already made the fatal mistake > of assuming that the existence of a cryptographically valid signature > *means* that the message is reliable and from a known "good" sender. You > could have a longer and more detailed discussion in the document about > how broken it is for a recipient to do such a thing, and put *that* into > the security consideration, but I don't think it's necessary. The above > can only obfuscate that very important point, making it out as if it's > something in the DKIM signing/verifying process that caused the problem. > > pr
I don't quite follow. There seems to be this effort to "remove a bad" (erroneous or not) connotation about DKIM (for some rubber stamping reason) when the facts are there is a strong possibility of a problem only because DKIM raises the bar or something in regards to "email." I strongly believe the mail industry never had a problem (at least I don't ever remember an exploit) because most, if not all, was designed to read mail for one FROM. There is no need to continue reading, reading from the bottom either, normal sequential reading for the From: field found. In other words, I doubt any software has a COLLECTION concept for From fields. Why when there there was no need for it. So the first one read was the one shown or the one used for gateway transformations, which is a strong point here - not every backend mail system stores mail in pure RFC x822/5322 format. I would like to see one software, any software that holds a structure for multiple froms? I doubt it exist. Hence, that is why we never saw the problem. But now with DKIM, it changes the issues somehow. DKIM allows for a perfect cryptographic valid signature for any bits it ignorantly signs and that includes all headers. In fact, I know of one API that without any IMPLEMENTATION controls - it will, by default, sign all headers, including if there exist multiple From: headers. You MUST recode the API if you want to invalidate the signing of an illegal RFC5322 message with multiple froms. Ironically, the same API did make a change to check for multiple froms during the verification process, but it did nothing on the signing side. I guess that might be ok when the design presumption is that the implementation of the API will make sure the input is valid during signing. In any case, I think the protocol should include both a functional and technical requirement for a ONE FROM criteria during the signing and verification process. I agree with Doug that at some point DKIM will have some "meaning" for validity and I think it is best that DKIM doesn't continue signing or verify an illegal RFC5322 message even if the mechanism allows for a valid abstract signature. Finally, in my implementation opinion, the only thing that makes me wonder is how far do we go to address the legacy verifiers who are not going to check for multi-from message. Do we add the h=From*n+1 kludge? Well, we decided that as long as we allow the h= setting to be flexible for the operator, then they can add it (we add it by default) as a short term solution. In the long term, I don't think it has to be used, but then again, I am strongly basing that that most DKIM implementations will eventually use a ONE FROM RULE criteria for both signing and verifying. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
