On Jul 31, 2006, at 12:26 PM, Dave Crocker wrote:
I would like to see a scenario described that explains exactly what
problem needs to be detected and why it is a compelling, immediate
requirement.
=====
Problem 1: Spoofs of the 2822.From email-address(es) common with
various phishing or spoofing attempts.
Solution A:
When the 2822.From email-address is not accompanied by a valid
signature from a parent domain, policy related to the 2822.From email-
address domain might provide a means to block spoofs of direct
messages. Acceptance would be denied when policy indicates 2822.From
email-address domain must be signed by a designated domain and this
condition has not been met.
Drawback of solution A:
a) A recipient can not differentiate direct messages from other
message types. The required use of a designated signing domain will
not conform to many common indirect services made on behalf of a
2822.From email-address such as mailing-lists or e-invites, for example.
b) The 2822.From email-address may not be visually apparent or may be
visually misleading. When just display-names are visible, or look-
alike or international domains are used, the recipient may be unable
to discern the exact 2822.From email-address being displayed.
-----
Solution B:
Track the tuple of 2822.From email-address domains and signing
domains at the MUA by way of the address book or correspondence log.
Annotate messages matching these tuples. This does not require that
a policy relationship be established.
Drawback of solution B:
This introduces a new requirement for MUAs to annotate and for the
tuple information to be exchanged between disparate MUAs for the same
user.
=====
Problem 2: Spoofs of visual content where 2822.From may also be
contrived to be visually misleading.
Solution C:
When a domain can be ascertained from the visual content of a message
and is not signed by a parent domain, policy related to the domain
identified by the visual content might provide a means to block
spoofs of direct messages based upon 2822.From policy. Acceptance
would be denied when policy indicates visual content must be signed
by a designated domain and this condition has not been met.
Drawback of solution C:
There is no reliable proactive means to identify cognitively similar
message content when ascertaining which policy should be applied.
This would not have a direct policy being expressed and may be highly
prone to false positives.
See Solution B.
=====
Problem 3: SMTP Host-name utilized within the administrative domain
by compromised systems.
Solution D:
Authenticate the reverse DNS hostname or EHLO and then reference DKIM
policy for the host-name for designated signing domains. A valid
DKIM signature by a designated DKIM domain would validate the
administrative' control of the message's introduction and satisfy the
conditions of the policy.
Drawback of Solution D:
There can be an immense number of DKIM domains associated with an
SMTP client host-name. While there are techniques to efficiently
resolve a name:name relationship using DNS (query of <signing-
domain>._policy-label.<related-domain>), the number of domains and
the maintenance of these relationships by a single administrative
domain may be daunting.
-----
Solution E:
Require a DKIM sanctioned method be used to authenticate SMTP client
host-names. For example an address RR must found at _dkim.<host-
name> that validates the client. The EHLO could also encompass the
_dkim.<hostname> as a means to avoid replicate A records and to
signal use of dkim at the EHLO.
Drawback of Solution E:
This would only protect systems that never send email and thus have
not been assigned a _dkim specific IP address.
=====
Problem 4: Replayed messages and bogus signatures are difficult to
detect.
Solution F:
By designating a direct relationship at the signing domain (&
2821.Mail_Froms) for designated host-names, invalid signatures should
be considered bogus and valid signatures should not be considered a
product of replay.
Drawback of solution F:
These relationships of possibly disparate administrative domains may
be daunting. These policies would not offer a basis to refuse the
message when a designated host-name is not discovered.
=====
Problem 5: Spoofing of the Current Address as determined by the
sequence of 2822.Resent-Sender, Resent-From, Sender, or From.
Solution G:
Reference a specific DKIM policy of the Current Address for
designated signing domains.
Drawback of Solution G:
This may lead to additional loading of the DNS server when some
verifiers attempt to validate every header field within the message.
As this field is not likely to be the target of a spoof, the added
overhead may be considered unwarranted.
=====
Problem 6: Spoofing of the 2821.Mail_From
See Solution F:
-----
Solution H:
Attempt to impose the 2822.From policy upon the 2821.Mail_From in
lieu of a separately defined policy specifically for the 2821.Mail_From.
Drawback of solution H:
Can only be used to bypass some checks. Lack of an association can
not be acted upon to refuse the message.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
