Doug,
Maybe its just late in the evening here, but a mail that starts with
a list of 16 new, old, borrowed, and blue, acronyms is not IMO a way
to make what you want to say easier to understand.
I'll read it again in the morning though, maybe it'll seem worth it
then;-)
S.
Douglas Otis wrote:
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
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html