Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 11, 2006.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document describes a mechanism permitting the DKIM signing domain to indicate different levels of reliance be given to specific messages by the recipient. This reliance indication is a security and safety enhancement when messages are selectively screened or annotated based upon generally trusted DKIM signing domains. Using this reliance mechanism, the signing domain better protects recipients by indicating low reliance levels when messages are from poorly-vetted sources. A low reliance level warns the recipient to increase the scrutiny given to such messages and also to appropriately limit message annotations. Without a means for a DKIM signing domain to partition the handling of their messages, their least vetted source may diminish the trust that might otherwise be established for their signed messages.

Table of Contents

1.  Introduction
2.  Definitions
3.  Reliance Level Assertion
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Introduction

Restoring trust in email requires establishing rigorous practices that are not prone to exploitation. These practices must also provide visible affirmations that are not easily circumvented. Visible affirmations can be automated folder selection, or annotations similar to message priority. For DKIM [I-D.ietf-dkim-base] (Allman, E., “DomainKeys Identified Mail Signatures (DKIM),” April 2006.), the signing domain can be affirmed when the domain of a verified signature is found within a list of trusted signing domains maintained by the recipient. Even a minimal amount of annotation conveying the list's affirmation, such as selectively indicating a reliance level, offers significant proactive protection from prevalent spoofing attempts. Even when the signing domain is not immediately visible, this protection is still achieved.

When only the display-name is visible or when internationalization is employed, email-address recognition remains an area increasingly prone to exploitation. Even expections that a significant email-address is apparent to the recipient can be confounded by valid emails where a purported originating email-address is not typically visible, or where this email-address is not within the signing domain, or where there is more than one purported originating email-address. The normally displayed content of a message is simply not assured to provide a clear indication of the actual signing domain or even the originating email-address.

Some advocate mechanisms that are based upon published use-profiles for email-addresses. These email-address use-profile mechanisms are nevertheless easily exploited. Protections based upon email-address use-profiles assume the recipient is able to recognize the email-address, and also recognize when requisite exceptions are being made. Use-profile protections still leave the recipient at risk when a deceptive email-address is mistakenly recognized as being from a trusted source. Use-profile acquisition can also greatly increase the overall overhead and convey information that is not verified by the DKIM signature.

Email-address use-profiles are of little value when a list of trusted DKIM signing domains is maintained by or available to the recipient. The DKIM signature is far better leveraged when affirmed by a trusted signing domain list. A trusted signing domain list offers proactive protection by enabling safer message annotation and screening. A trusted signing domain list strategy does not depend upon the recipient's visual acuity, or upon reactive block lists of similar-looking domains held by bad actors. The trusted signing domain list could be compiled and maintained by the recipient or by a trusted community of users. When first subscribing to services from a reputable entity and then receiving a message containing their pass-phase, this method of introduction allows a recipient to safely add the signing domain to their list of trusted signing domains.

Any signing entity may find that some messages being signed are from poorly-vetted sources. An inability of the recipient to distinguish well-vetted sources substantially reduces the trust that the signing domain may desire to retain for these specific sources. While signing domains could partition email-addresses into sub-domains in order to consolidate similarly vetted sources, this approach will likely confuse recipients with respect to what is to be trusted.

The absence of a partitioning mechanism may actually induce a bad practice of using multiple domain names, which includes the use of sub-domains. Partitioning by changing the right hand side of the email-address is currently the only method available to signing domains wishing to retain trust for a specific category of messages. The added complexity induced by an increase in domain names may enable an increase in exploitations. Delegating trust differentially at the sub-domain is also disruptive with the need for email-address reassignment. To avoid this outcome, the signing domain must be provided a means to partition the vetting of message sources within a common domain at the outset of DKIM deployment.

Partitioning by way of email-address use-profiles requires two additional sequential transactions, a separate use-profile for both the right and left hand side of the email-address. Email-address use-profiles of the left hand side, as a means to partition the domain, also represent a significant increase in the number of requisite transactions. The Reliance Level parameter as described below avoids this inordinate overhead.

A simple Reliance Level parameter, added to the DKIM signature and the key, provides the signing domain a means to partition their sources. This partitioning reduces possible damage by being able to act as a warning for recipients. The reliance level warning thereby retains greater trust for messages at a higher reliance level. The application of this mechanism does not require additional overhead when assessing the message. The reliance mechanism can directly and immediately affect message handling and annotation. The Reliance Level parameter better ensures precautions are not inappropriately bypassed for specific messages, even for those from otherwise generally trusted domains.

2. Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3. Reliance Level Assertion

The Reliance Level parameter allows the signing domain a means to partition internal sources into three categories. When the Reliance Level parameter is optionally omitted at either the key or the signature, the Reliance Level defaults to Normal. The Reliance Level indicated within the signature header field must not exceed the Reliance Level indicated within the key, or the signature SHOULD be considered invalid. An indication of a Low Reliance Level warns the recipient to be cautious, whereas a High Reliance Level offers added assurances by the signing domain.

The Reliance Level uses the "r=" tag in both the signature and key, where the value is represented as a plain-text signed decimal integer. The Low Reliance Level has the negative value -1. The Normal Reliance Level has a value of 0, and the High Reliance Level has a positive value of 1. Values greater than 1 or less than -1 are undefined. For message handling, these undefined values SHOULD be considered equivalent to a value of 1 or -1 respectively to permit future enhancements.

4. IANA Considerations

The parameter prefix 'r=' used in both the DKIM signature and DKIM key will require registration by IANA.

5. Security Considerations

This document describes an option for adding a DKIM signing domain assertion. The recipient is not expected to reliably recognize an email-address for many reasons, where the signing domain assertion improves upon the safe handling and annotation of DKIM signed messages. In general, special handling is required before DKIM offers the recipient any added protection, as the DKIM signature itself is intentionally transparent. This special handling may include annotation or content screening. When the recipient elects to trust the signing domain, the signing domain should also be able to directly offer their vetting assessments to better protect this trust. Without the signing domain's assessment, recipients are unable to discern any differences in the signing domain's vetting of the message source and would need to handle all messages in the same manner.

DKIM does not require that an email-address be within the signing domain. Even when the DKIM signature references a specific email-address contained within the signing domain, there is no means to impart to the recipient the level of vetting that was achieved by the signing domain, without the reliance mechanism. While the recipient may attempt to make separate assessments of the referenced email-address, such assessments may further burden the recipient and would be based upon information not verified by the DKIM signature.

6. References

6.1. Normative References

6.2. Informative References

Author's Address

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

Copyright © The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.