Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack, why RFC 5322 compliance is a fuzzy term, and what about malformed MIME str
Murray S. Kucherawy wrote: It boggles my mind that a specification called DomainKeys Identified _MAIL_ has to be explicit about the fact that the input is expected to be formatted like a mail message, and that there's even pressure to say in a normative way that someone implementing this has to make sure that's the case. Security Considerations of RFC5451 was updated to include language about hardening against input deliberately crafted to try to confuse or crash applications, and I was surprised that they (secdir) felt that was necessary; I expected that to be fairly obvious to anyone in the audience of a standards track RFC. (It wasn't required to be normative, however.) In my view of the IETF RFC documents, its a matter of technical writing style. They are neither a 100% Functional Specification nor 100% Technical Specification, but a blend to help reach a wider audience of disciplines. A good amount of expertise and/or experience is required to get the message across and it also requires a good amount of expertise/experience to be able to read the message to both a) extract and b) extend the engineering insights required to produce the protocol. In this case, in my technical opinion, Section 5.4 has incomplete implementation insights regarding the single field requirements for RFC 5322. It is an insight that would of been included if we had seen the issue when it was first written four years ago, especially when we went through the TA process. -- 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
Re: [ietf-dkim] Necessary Verifier Actions to mitigate exploitation of trust established through DKIM signatures.
Append to Section 6 Verifier Actions: It is not reasonable to assume a message is in compliance with RFC5322. To mitigate trivial exploitation of trust established by DKIM signatures, messages having multiple header fields for orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, or subject MUST always return PERMFAIL for any DKIM signature associated with the message. When there are multiple singleton header fields, a field selected for display or sorting is therefore undefined. Likely top-down selections by consumers of DKIM status where the signature verification selects bottom-up leaves singleton headers highly prone to trivial exploitation. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
