On 5/2/11 10:22 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From:ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Rolf E.
Sonneveld
Sent: Monday, May 02, 2011 1:14 PM
To:dcrocker(_at_)bbiw(_dot_)net
Cc:ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain
Identity"
In other words, DKIM has nothing to do with the rfc5321.From field, and
therefore it is entirely inappropriate -- that is, out of scope -- for the
specification to suggest dealing with it.
You mean 5322.From?
Yes, I think that's what he meant.
And how should we read par. 3.2.2 of RFC4686 if it is out of scope for
DKIM to deal with it?
Bad acts related to email-based fraud often, but not always, involve
the transmission of messages using specific origin addresses of other
entities as part of the fraud scheme. The use of a specific address
of origin sometimes contributes to the success of the fraud by
helping convince the recipient that the message was actually sent by
the alleged author.
To the extent that the success of the fraud depends on or is enhanced
by the use of a specific origin address, the bad actor may have
significant financial motivation and resources to circumvent any
measures taken to protect specific addresses from unauthorized use.
When signatures are verified by or for the recipient, DKIM _is
effective in defending against the fraudulent use of origin addresses_
on signed messages.
Although 5322.From is not mentioned here, how can DKIM provide any level
of defense against fraudulent use of origin addresses, if d= is the one
and only mandatory output of the verification process?
Why does the output of DKIM need to include something when the consumer of
that output already has that information?
Because a consumer should/must not have to re-do the work of the DKIM
verifier. Or put it differently: a consumer is just consuming the output
of the DKIM verification process, it will rely on it (provided there's a
trust relation between consumer and verifier), and it normally will not
re-do the work of the DKIM verifier. It has no knowledge of DKIM rules
(bottom up etc.). Just like a MUA has no information about how two MTA's
exchange a mail over SMTP.
So for the consumer it is essential to get, in addition to the d= and
the status, the From address that was used to construct the signature.
That way the consumer can act upon this triplet of information.
Or should we declare this paragraph obsolete?
It could stand some revision, I suspect.
Nevertheless, the overall threat model doesn't require that DKIM itself, i.e.
the protocol being defined, also be the thing that evaluates origin addresses
for validity or value.
Agreed.
It's certainly legitimate to leave that to other modules, just like SMTP
isn't required to do any evaluation work of the payload it carries.
Agreed.
But DKIM is a key component to that overall system.
Because DKIM is a key component to the overall system, it must provide
reliable information about the origin address to those 'other modules'.
If DKIM is not designed to provide that, we'll have to declare par.
3.2.2 of RFC4686 to be 'status: historical'.
Question: does DKIM say anything about the 5322.From header value? If we
agree with Dave, we'll have to admit that DKIM does not address the
threat described in par. 3.2.2 of 4686, do you agree?
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html