Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On 26/Oct/10 19:08, Murray S. Kucherawy wrote: On Behalf Of Alessandro Vesely On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? In a bunch of ways. In particular, though, it is deliberately not RFC2119 language, partly because that's not generally done in Security Considerations since that section is discussion (informative) rather than protocol (normative). But it affects the result! That way a verifier is encouraged to determine the validity of a signature based on heuristic criteria. This kind of checking belongs to scam filters a la SpamAssassin. Now, SA doesn't do it. Possibly, that's because it's statistically irrelevant. AFAIK, SA does not even analyze Authentication-Results, but re-checks signatures anew. Why? Suppose one day the double-From attack becomes trendy and SA developers will want to write code that checks for the valid-signature + added-From pattern. They would never be able to use A-R, because those results might be flawed by such non-normative arrangements: This is where that layer violation hurts. According to that text, it is strongly advised to have a scam filter /integrated/ within a DKIM verifier. Doesn't this slash the value of stand alone verifiers and A-R fields? JM2C ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/10 9:36 PM, Murray S. Kucherawy wrote: On Monday, October 25, 2010 2:48 PM, Douglas Otis wrote: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. Bad advice. There is no other email component that can be relied upon to restore flawed DKIM verification results, nor should DKIM relegate determination of DKIM result validity to subsequent consumers. But neither of those was the suggestion. A DKIM Signature Verification returning PASS when there are multiple From header fields provides information that REQUIRES additional checks before it can be safely employed by _any_ consumer of DKIM results. In nearly every case, such a message is the result of a bad actor attempting to exploit the lack of essential conformance checks. Subsequent checking of DKIM results represents a clear protocol layer violation, where this checking SHOULD be done by DKIM. Suggesting that omitting these checks is okay represents Bad Advice. The DKIM protocol MUST require checks that are critical to the safe use of DKIM results, and not simply document the mistaken omission of these checks that implies subsequent consumers of DKIM results are expected to make these checks instead, or expected to have a header selection process of what should be a singular header field conform with DKIM's bottom-up processing. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the h= portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). Incomplete advice. This only provides partial protection, since it does not prevent spoofing of a From header where an attacker controls or utilizes a domain that does not include repeated From header entries within the h= parameter. I'm having trouble parsing that. Please propose alternate text, or show an example of what you're describing. I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Reputation can not fix this problem. Fobbing this onto the consumers of DKIM results goes against the goal of increasing trust in email, and against the spirit of doing our best at providing accurate results. Let's fix our mistake. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
Douglas Otis wrote: I'm having trouble parsing that. Please propose alternate text, or show an example of what you're describing. I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Reputation can not fix this problem. Fobbing this onto the consumers of DKIM results goes against the goal of increasing trust in email, and against the spirit of doing our best at providing accurate results. Let's fix our mistake. The lack of focus for 1st party domain protection is what allowed this issue to fall through the crack. We tried our best to make DKIM a pure signing mechanism with an open ended implicit policy of unrestricted resigners, remolding the specs with out of scope wink wink design goals. MLM allowance or tolerance became a dominant goal over the principle benefit DKIM can provide - 1st party DOMAIN protection. The solution is an integrated solution. DKIM itself can not solve this. At this point, what's missing are HANDLING provisions for DKIM verifiers. A real POLICY protocol with 3rd party considerations is really the only thing that can help resolve this problem. Even Reputation Vendors can help here but they need to support POLICY too. Instead, the pressure has been to eliminate it. -- 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
