John R. Levine wrote: >>> Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. >> 50% agreed. This mistake is only in DKIM, IMHO. > > At this point, it would be helpful if you could propose specific language > for 4871bis. And if it's not presuming 5322 compliance, it would also be > helpful if you could say in detail what a DKIM signer and verifier should > do if presented with, say, a Windows executable file. Not a MIME encoded > message body containing one, just an EXE file. If you don't require 5322 > compliance or something close to it, that's as legitimate a signing > candidate as anything.
Based on the discussions, providing the proper technical does not seem to be problem, but rather how it conflicts with satisfying IETF RFC passage guidelines to avoid yet another WG review cycle. All that aside.. IMV, it was not a mistake to presume 5322 compliance. All mail processing components begins with that basic design presumption. But it was mistake to presume specific DKIM related input requirements can be violated or incorrect and yet be ignored or not checked due to the subjective software engineering idea that it a protocol Layer violation and thus isn't a DKIM technical responsibility to make sure these DKIM related specific input parts are correct. In other words, since a RFC5322 presumed compliance carries over a concept that there MUST be only one 5322.From, there is a solid Software Engineering (SE) design consideration for the DKIM input requirement protocol to take this into account. A robust function generators will check for its boundary conditions and the mistake is in the failure to recognize this SE design consideration. While it is a valid SE consideration to avoid this is an optimization or lower overhead consideration, but that should not preclude the idea that the SE design semantics not be part of the functional specification. For example: Section 5.4 speaks in generic terms regarding signing the last instance (from the top, with the presumption that this last instance is the first introduction of the header) only but failed to highlight the design requirement for a specific single field only 5322.From requirement as it relates to a) RFC5322 correct DKIM signature output and b) RFC 5322 compliance itself. It is (A) that is most important here and this is where the corrective text should be added. The original ISSUE Posting included proposed text to follow the "last header" paragraph in Section 5.4: Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. With all the WG participant since then, the above can be better clarified, but my main point here is that Section 5.4 is where the reader is learning how to implement the logic related multiple headers and it is here where the reader should be quickly made aware of the RFC5322 compliance reminder and exception to the "Last Header" guideline. I think a new security Section 8.14 is needed to further describe the "reason" for the exception in 5.4. I think my version is better than Murray's but I don't really care about that. Probably, what is also needed that will really help implementators are "tips" and "methods" to address this with an eye to how realistically DKIM components are added or integrated to a system. But I believe this can be done first by simply stating: DKIM implementators can mitigate this issue by adding 5322.From checking in their verifiers and signers. The 5322.From checking can also be done at the integration points such as MTA receivers. The problem is the next statement because it appears to have IETF conflicts: It is HIGHLY RECOMMENDED for all DKIM verifiers to ALWAYS perform a multiple 5322.From header check and return an invalid signature when two or more 5322.From headers are found. Putting aside the IETF conflicts, by making this a new fundamental 4871bis requirement for DKIM verifiers to perform this check, it would be begin to address the problem to a very high degree. But at the end of the day, it is an integrated solution. DKIM can not work by itself. It works when integrated with other parts; MSA, MDA, MTA, MLS/MLM and MUAs both online and offline. As a generic protocol, DKIM can offer a solution for this specific multiple 5322.From header fault at the verification and signing process and we should provide DKIM software writers the insight to consider it when providing tools to the DKIM integrators. It will be the DKIM integrators who will decide how to use the DKIM tools provided depending on what the other integrated parts can do or not do. The "total" solution is an integrated one and since this belated highlighted ISSUE has now shown it is also a problem for non-DKIM streams, integrators are now smarter about the issue and will most systems will begin to do more RFC5322 checking prior to any DKIM processing or display to users. -- 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