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: [email protected] From: [email protected] 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
