...
A Proposed DKIM deployment experiment for the Higher Education community
RL "Bob" Morgan, University of Washington and Internet2
The ubiquity and importance of the Internet have created new requirements for many Internet protocols regarding security. Users of protocols supporting the domain name system, email, routing, instant messaging, telephony, the web, and more are faced with the fact that Internet participants have a wide variety of interests, some of them actively malicious or criminal. Security requirements have been developed and capabilities have been added to many widely-used protocols, but in many cases the new security features are not being deployed, leaving security problems to be solved by workarounds or not solved at all. The reasons for non-deployment are varied and hard to assess, but often have to do with the network effect, or its absence: there's little utility in deploying a particular security protocol until everyone else does too, so no one makes the initial effort.
The Internet Society (via its Trust and Identity Initiative), the Internet2 Middleware Initiative, and the InCommon Federation are interested in promoting the adoption of standard technical methods that enable a safer and more trustworthy Internet, and are partners in efforts to lower deployment barriers for promising Internet security technologies. One such technology is DKIM.
DomainKeys Identified Mail (DKIM), specified in RFC 4871, is an email security framework whose "ultimate goal ... is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey." After verification, "an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation." The reputation and practices of the signer can then serve as valuable input into further message processing, providing a positive basis for disposition in ways that heuristics on unauthenticated elements cannot. A community of trust such as existing higher-education identity federations can act as a solid source of reputation.
DKIM deployment is not "a solution to the spam problem" but may be one of many tools useful in reducing the negative effects of email abuse. The DKIM RFC was published in May 2007. DKIM builds on the older pre-standard DomainKeys specification which has been in use since about 2005. Some large email providers are promoting the use of DomainKeys and DKIM today. However, deployments are still very few, especially in the higher-education community which historically has been a leader in socializing new Internet technology.
We propose an experiment to assess the value of a deployment of DKIM among a set of higher-education institutions in the US and in other countries. It is an experiment (rather than a pilot) because the utility and applicability of the technology is still the major question. The proposed plan has these steps:
...
- Do signing domains need to state what their signing means, aka what their signing practices are?
- How does this relate to email outsourcing? Might institutions that have outsourced some or all of their email want their providers (e.g. Google, Microsoft) to sign/verify?
- Can all outgoing email be signed or just a subset? if a subset, how is it chosen?
- How does email signing integrate into outbound email processing? Does signing require massive CPU power or cause delivery delays?
- How does validation integrate into inbound mail processing and policy?
- Does DKIM provide benefits to email for the defined community that make it worth deploying? For example, does it solve problems like improving delivery success of mail to alumni and students using commodity email services?
- Is DKIM deployment useful prior to availability of standard signing-practices methods?
- What interoperability problems exist among differing implementations?
- What is the effect of failure cases (message validation failure due to modifications in transit, etc)?
...