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: accounts(_at_)big-bank(_dot_)com
From: someone(_at_)big-isp(_dot_)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