... Apparently, RFC 5617 already
provides for multiple author addresses. Section 3 reads
If a message has multiple Author Addresses, the ADSP lookups
SHOULD be performed independently on each address.
No, that wording applies to multiple addresses in a single From header. If
there are two From headers, ADSP has nothing to say on which to use, so
the expectation is that its implementations will use the first, when asked
to to an ADSP lookup. The whole point of this scam is that big-isp.com
(the Bad Guy in this case) wants to prevent that lookup from ever
happening. As the two specs (DKIM and ADSP) are currently written, his
scam will succeed.
Charles,
It should be noted that this single 5322.From header with multiple
address values scenario was discussed at length in the past with the
original SSP draft and the consensus was that SSP checkers should use
the first address domain. From the August 2006, SSP draft rev02
draft, section 2.3:
http://tools.ietf.org/id/draft-allman-dkim-ssp-02.txt
2.3. Originator Address
The "Originator Address" is the email address in the From header
field of a message [RFC2822], or if and only if the From header field
contains multiple addresses, the first address in the From header
field.
NON-NORMATIVE RATIONALE: The alternative option when there are
multiple addresses in the From header field is to use the value of
the Sender header field. This would be closer to the semantics
indicated in [RFC2822] than using the first address in the From
header field. However, the large number of deployed Mail User
Agents that do not display the Sender header field value argues
against that. Multiple addresses in the From header field are
rare in real life.
As noted that this very rare, to cover all security angles regarding a
possible domain order relationship of the addresses, IMO, ADSP is
technical correct in stating it SHOULD check each domain value.
I seem to recall citing a method that can help decide the order of
checking the domains using the sender or the signer domain. If the
signer domain matches any of the single 5322.from header with multiple
domains, it might consider checking this domain policy first with the
idea the 1st party signature is more important (trust wise) than a 3rd
party domain. It can also use logic to compare the Sender.
For example:
Sender: tom(_at_)domain3(_dot_)com
From: bob(_at_)domain1(_dot_)com, tom(_at_)domain3(_dot_)com,
jane(_at_)domain2(_dot_)com,
sally(_at_)domain4(_dot_)com
DKIM-Signature: d=domain2.com
There is reasonable logic here to suggest the domain policy lookup
order might be:
domain2.com - check for 1st party policy
domain3.com - check for a "Sender" policy
domain1.com - check remaining in order presented
domain4.com
existing ADSP implementations would still get caught. SO we MUST fix it in
DKIM, which IS on our agenda.
Technically, in the name of protocol consistency, if there is no DKIM
signature, POLICY is still part of the handling framework. This was
highlighted in the Threats Analysis (TA) RFC4686 and the SSP
Functional Requirements RFC5016 in how it related to failed signature
and also 1st party versus 3rd party signatures.
Overall, if there was probably one absolute majority consensus among
all sides of the policy question, was the solid TA recognition that a
valid 1st party signature was a solid reason to short-circuit (skip) a
policy lookup. This is codified in RFC5016 section 5.3 item #9:
9. SSP MUST NOT be required to be invoked if a valid first party
signature is found.
So policy is still active when there is no valid signature.
Multiple listings of singleton header fields in the h= parameter is
an ugly and wasteful hack that offers an incomplete remedy for
these selection conflicts.
Yes it is ugly but, worse, it does not prevent this particular scam.
I don't particular like the kludge, but that should not mean it could
not be mentioned as part of the specification as a possible "feature"
DKIM API writers or implementors to consider to cover all bases. In
other words, the functional spec (ideally) should just mention all the
known possible methods software engineers can consider to mitigate the
potential exploit.
1 - Integrate DKIM with mail system components that can perform
RFC5322 compliance checking with a focus on multiple 5322.From
violations.
Note: As a new general consideration, all MTA/MUA developers
should consider implementing this multiple 5322.From checking,
if not done already, as a general practice.
2 - Include specific RFC5322 checking for items that are related
to the DKIM verification or signing process. i.e. check for
multiple 5322.From headers.
3 - Consider a multiple h=from:from...[:from] N from values to
force invalid signatures when N+1 5322.From headers are found.
Overall, we should emphasize that all DKIM verifiers SHOULD perform
this check or offer an option to check for this specific double
5322.From violation to address integration models where it is not
possible for MTA receivers to perform this checking.
The above is all I would need as a software person to weigh all design
and integration decisions and/or what to make available to operators.
For us, we learned that we can best address this a
SMTPFILTER-CHECK-RFC5322 filter at our MTA receiver for all inbound
messages. Like Murray, I believe this is prudent and the best
approach. But unlike Murray, from a generalize protocol standpoint
adding DKIM to a product line, I know I can not enforce this method
with all MTA systems which may not have the capability or level of
software options to do this checking at a MTA. So the DKIM verifier
and signer protocol components or API SHOULD also provide a mitigating
solution when specific MTA integration models does not provide an answer.
--
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