Document Status: Discussion Draft
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:
- Engage a number of institutions.
Engagement would require participation from a skilled email technologist and, preferably, an analyst or architect. The email technologist should be familiar with modern email processing methods and should be responsible for technical decision-making for the institutional email system. Engagement would also imply willingness and ability to make changes to at least a portion of the production email service for the institution in support of the experiment. We will also attempt to take advantage of existing trust communities such as InCommon (in the US), Swamid (in Sweden), and the UK Access Management Federation. - Design the experiment.
The experiment would consist of deployments of DKIM signing and verification services at the participant institutions, including key management and distribution, and modifications to spam processing. It would also include logging/monitoring components so statistics can be compiled on usage. - Conduct the experiment.
It would run for a defined period of time, perhaps six months. Participants would communicate status and stats throughout, and modify operations as needed. - Report results.
Questions the experiment could address:
- 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)?
An initial planning event will be held at the 73rd IETF meeting in Minneapolis on Sunday November 16. Attendees would be encouraged to stay for the rest of the IETF meeting, including the DKIM WG meeting on Monday November 17.