Internet DRAFT - draft-otis-dkim-reliance-level
draft-otis-dkim-reliance-level
DKIM D. Otis
Internet-Draft Trend Micro, NSSG
Expires: November 11, 2006 May 10, 2006
DKIM Signing Domain Reliance Level
draft-otis-dkim-reliance-level-00
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 (C) 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
Otis Expires November 11, 2006 [Page 1]
Internet-Draft DKIM Reliance May 2006
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Reliance Level Assertion . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Otis Expires November 11, 2006 [Page 2]
Internet-Draft DKIM Reliance May 2006
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], 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-
Otis Expires November 11, 2006 [Page 3]
Internet-Draft DKIM Reliance May 2006
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
Otis Expires November 11, 2006 [Page 4]
Internet-Draft DKIM Reliance May 2006
document are to be interpreted as described in [RFC2119].
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.
+-------+------------------------------+
| Level | Description |
+-------+------------------------------+
| r=-1 | Low Reliance (poorly-vetted) |
| r=0 | Normal Reliance (default) |
| r=1 | High Reliance (well-vetted) |
+-------+------------------------------+
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
Otis Expires November 11, 2006 [Page 5]
Internet-Draft DKIM Reliance May 2006
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
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail Signatures
(DKIM)", draft-ietf-dkim-base-01 (work in progress),
April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Otis Expires November 11, 2006 [Page 6]
Internet-Draft DKIM Reliance May 2006
Author's Address
Douglas Otis
Trend Micro, NSSG
1737 North First Street, Suite 680
San Jose, CA 95112
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires November 11, 2006 [Page 7]
Internet-Draft DKIM Reliance May 2006
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 (C) 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.
Otis Expires November 11, 2006 [Page 8]
