ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Are verifiers expected to query SSP on a successful verify?

2006-08-01 15:58:04

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