This explores a range of possible policy and auxiliary records and
label scenarios as a general exercise. Rather than repeating the
same phase fairly often, acronyms are still used, but now are defined
up front. The expected drawbacks are retained to help with their
eventual disposition.
Definitions of Terms
--------------------
Resource Record (RR): The storage element selected by type used by
DNS containing structured content.
Resource Record Set (RRset): One or more Resource Records at a
specific domain name.
Originator Address (OA): An email address found within the 2822.From
header field.
Originator Address Domain (OAD): The domain of an OA.
Current Address (CA): The latest dominant email-address introduced
per RFC2822. (The latest 2822.Resent-Sender, Resent-From, Sender, or
From.)
Current Address Domain (CAD): The domain of an CA.
Mail From Domain (MFD): This represents the domain within the
2821.Mail_From parameter.
Signing Domain (SD): The domain verified by a valid signature located
by DKIM-Signature header field 'd=' parameter.
Policy Publishing Domain (PPD): The domain from where policy is
published, excluding any special prefix for referencing the policy RR.
Designated Signing Domain (DSD): A domain contained within policy
providing authoritative signatures for the PPD.
Non-Designated Domain (NDD): A domain not contained within policy and
not considered authoritative for the PPD.
Designated Host-Name (DHN): A host-name designated as being
authoritative for the PPD.
Direct Message (DMSG): A message issued and signed by the OAD.
Indirect Message (IMSG): A message issued on behalf of the OA and
signed by a NDD.
Signature/Address Tuple (SAT): The OA combined with either a valid
signature by a DSD or a DMSG.
--------------------
=========
Problem 1: Spoofs of the OA in phishing attempts.
Solution A:
In the case of IMSGs, OAD policy might provide a means to block
spoofs of DMSGs. Acceptance could be denied when OAD policy
indicates exclusive use of DSDs, and the SD is not in conformance.
Drawback of solution A:
a) A recipient can not differentiate DMSGs from IMSGs. Exclusive use
of DSDs will not conform to common IMSG related services, such as
mailing-lists or e-invites. Policy may be ignored (see Solution B),
the message may be annotated to indicate a level of policy assertion
conformance, or the message may be refused when not conforming with
policy assertions.
b) The OA 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 OA being displayed.
-----
Solution B:
Track SATs at the MUA with an address book or correspondence log, and
then annotate messages matching an SAT. This does not require policy
be obtained to prevent spoofing and this also resolves look-alike
issues.
Drawback of solution B:
This introduces a new requirement for MUAs to annotate messages based
upon SATs, where this information should also be exchanged between
disparate MUAs for the same user.
=========
Problem 2: Spoofs of visual content where the OA may also be
contrived to be visually misleading in phishing attempts.
Solution C:
When a domain can be ascertained from the visual content of a
message, this domain can be checked for DSD conformance with OAD
policy at this domain. Acceptance could be denied when OAD policy
indicates exclusive use of DSDs, and the SD is not in conformance
with this policy.
Drawback of solution C:
There is no reliable proactive means to identify cognitively similar
message content when ascertaining the domain. Being a niche problem,
this would not likely have a specific policy expressed, and the lack
of conformance with OAD policy may be prone to false positives.
-----
See Solution B.
=========
Problem 3: SMTP host-name are utilized within administrative domains
by compromised systems for sending abusive messages, both signed and
unsigned.
Solution D:
Authenticate the reverse DNS host-name or EHLO and then reference a
host-name policy providing DSDs where the left-most host-name label
is not used for the reference. A valid DKIM signature by a DSD then
validates the administrative' control of the message's introduction
and demonstrates conformance with the policy.
Drawback of Solution D:
There can be an immense number of DSDs associated with an SMTP client
host-name. While there are techniques to efficiently resolve a large
name:name relationship using DNS (query of <signing-domain>._policy-
label.<publish-domain>), the maintenance of these relationships by an
administrative domain may be daunting.
-----
Solution E:
Require that 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> 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 would
not have an assigned _dkim specific IP address. However, a
compromised system implementing DKIM signing seems unlikely protected
by supplemental policies or records. This protection would require
some means to assert that host-names must provide SDs within the same
domain, and hope that the private key was not also obtained.
=========
Problem 4: Replayed messages and bogus signatures are difficult to
detect and effectively triage.
Solution F:
Publish a policy that returns DHNs at SDs. After verifying the host-
name, and finding a DHN association at the SD, invalid signature at a
DHN can be considered bogus, and valid signatures at a DHN should not
be considered the 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 a
message when a DHN is not established.
=========
Problem 5: Spoofing of the CA, when the CA is not also the OA.
Solution G:
When the CAD is not within the SD, reference a specific CAD policy
for DSDs and check for conformance.
Drawback of Solution G:
This may lead to additional loading of the DNS server when some
verifiers attempt to validate additional header fields 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 MFD.
See Solution F, except replace SD with MFD.
-----
Solution H:
Attempt to impose the OAD policy upon the MFD, in lieu of a policy
specifically for the MFD. This may short-cut some checks and prevent
some possible handling delays.
Drawback of solution H:
Can only be used to bypass some checks. Lack of an DSD association
corresponding to the MFD can not be acted upon for refusing messages.
-----
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html