Internet DRAFT - draft-otis-dkim-adsp
draft-otis-dkim-adsp
DKIM Working Group D. Otis
Internet-Draft Trend Micro, NSSG
Intended status: Standards Track June 25, 2008
Expires: December 27, 2008
DKIM Author Domain Signing Practices (ADSP)
draft-otis-dkim-adsp-04
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 December 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
DomainKeys Identified Mail (DKIM) as described in [RFC4871], defines
a domain-level authentication framework for email to permit
verification of the source and contents of messages. This document
specifies an adjunct mechanism to aid in assessing messages that lack
valid DKIM signatures for domains used in the author's address. It
defines a record that can advertise the extent to which a domain
signs outgoing mail that is publicly exchanged on SMTP port 25, as
described in [RFC2821]. Also, how other hosts can access those
Otis Expires December 27, 2008 [Page 1]
Internet-Draft ADSP June 2008
records.
Advertisements, defined by this document, may also increase DKIM
signature expectations for messages received by Mail User Agents
(MUAs) or for messages which might have been exchanged over protocols
other than SMTP. In some circumstances, author domains may wish to
have accommodations for protocol failures or for mixed public
protocol messaging not to be made.
In addition, DKIM's identity parameters related to the author address
are decisive only when a corresponding DKIM key local-part template
precludes an author address. DKIM in conjunction with ADSP is to
provide methods for detecting the spoofing of known domains, but not
for making strong assertions about the identity of the message
author.
Otis Expires December 27, 2008 [Page 2]
Internet-Draft ADSP June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Terms Imported from DKIM Signatures Specification . . . . 4
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5
2.3. Valid Author Signature . . . . . . . . . . . . . . . . . . 5
2.4. Key Domain . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Author Key Domain . . . . . . . . . . . . . . . . . . . . 5
2.6. Author Address . . . . . . . . . . . . . . . . . . . . . . 5
2.7. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5
2.8. Author Domain Signing Practices . . . . . . . . . . . . . 6
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. ADSP Discovery Results Usage . . . . . . . . . . . . . . . 6
3.2. ADSP Discovery Results . . . . . . . . . . . . . . . . . . 6
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7
4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. References - Normative . . . . . . . . . . . . . . . . . . 13
7.2. References - Informative . . . . . . . . . . . . . . . . . 14
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 14
A.1. Single Location Domains . . . . . . . . . . . . . . . . . 14
A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15
A.3. Commonly Forged Transactional Messages . . . . . . . . . . 15
A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Appendix C. Update History . . . . . . . . . . . . . . . . . . . 16
C.1. Changes to draft-otis-dkim-adsp-00 . . . . . . . . . . . . 16
C.2. Changes to draft-otis-dkim-adsp-01 . . . . . . . . . . . . 16
C.3. Changes to draft-otis-dkim-adsp-02 . . . . . . . . . . . . 16
C.4. Changes to draft-otis-dkim-adsp-03 . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Otis Expires December 27, 2008 [Page 3]
Internet-Draft ADSP June 2008
1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a Key Domain to
claim responsibility for the introduction of a message. Receiving
hosts can verify the signature by querying the Key Domain to retrieve
the appropriate public key, and thereby confirming that a message has
been attested to by a party in possession of the private key and in
control of a portion of the Key Domain.
However, the legacy of the Internet is such that not all messages
will be signed or will retain a valid signature, and that absence of
a valid signature on a message is not an "a priori" indication of
forgery. In fact, during early phases of deployment, it is likely
that most messages will remain unsigned. However, some domains might
decide to sign all of their outgoing mail, for example, to better
protect their brand name. It is desirable for such domains to be
able to advertise that fact to other hosts. This is the premise of
Author Domain Signing Practices (ADSP).
Receiving hosts implementing this specification ensure greater safety
by first inquiring into the validity of the SMTP domain before
attempting a series of transactions related to DKIM validations. The
transactions pertaining to this document determine Author Domain
Signing Practices advertised by the Author Domains. This
determination is called ADSP Discovery.
The detailed requirements for Author Domain Signing Practices are
given in [RFC5016]. This document refers extensively to [RFC4871]
and assumes the reader is familiar with it.
Requirements Notation: 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]
2. Language and Terminology
2.1. Terms Imported from DKIM Signatures Specification
Some terminology used herein is derived directly from [RFC4871]. In
several cases, references in that document to Sender have been
changed to Author here, to emphasize the relationship to the Author
address(es) in the From: header field described in [RFC2822].
In addition, [RFC4871] requires that a valid signature having a
restrictive local-part template, the key's "g=" tag and value, must
Otis Expires December 27, 2008 [Page 4]
Internet-Draft ADSP June 2008
match against an undefined "signing address". The "signing address"
could be understood to be the email address associated with the
signature's "on behalf of" identity which would be the "i=" tag and
value or its default, but the benefit of this check is limited since
DKIM signatures are not normally displayed. This document seeks to
clearly define the "signing address" used in conjunction with a
restrictive key's local-part template as being the "Author Address".
Briefly,
o The "local-part" is the part of an address preceding the "@" sign,
as defined in [RFC2822] and used in [RFC4871].
2.2. Valid Signature
A "Valid Signature" is any message signature which correctly verifies
using procedures described in section 6.1 of [RFC4871].
2.3. Valid Author Signature
A "Valid Author Signature" is any message signature which correctly
verifies using procedures described in section 6.1 of [RFC4871], and
where the local-part template, the key "g=" tag and value, and the
Key Domain, match against the Author Address.
2.4. Key Domain
The "Key Domain" is the domain listed in the "d=" tag of a Valid
Signature.
2.5. Author Key Domain
The "Author Key Domain" is the domain listed in the "d=" tag of a
Valid Author Signature that is at or above the Author Domain. The
Author Key Domain must match all of its domain components with that
of the Author Domain. When a referenced Key contains a "t=s" tag and
value, the Author Key Domain will contain the entire Author Domain
for the signature to be valid.
2.6. Author Address
An "Author Address" is an email address in the From header field of a
message [RFC2822]. If the From header field contains multiple
addresses, the message has multiple Author Addresses.
2.7. Author Domain
An "Author Domain" is determined by the entire right-hand-side of the
Author Address (the portion that is to the right of the "@",
Otis Expires December 27, 2008 [Page 5]
Internet-Draft ADSP June 2008
excluding the "@" itself).
2.8. Author Domain Signing Practices
"Author Domain Signing Practices" (or just "practices") consist of a
machine-readable record published at the "_adsp." subdomain of the
Author Domain. The ADSP record includes statements about outgoing
mail practices for messages containing the Author Domain.
3. Operation Overview
Domain owners can publish Author Domain Signing Practices via a
distribution service, such as the Domain Name System; specific
details related to the use of DNS are given in Section 4.1.
Hosts can obtain Author Domain Signing Practices of the domain(s)
specified by the Author Domain as described in Section 4.2.2. If a
message has multiple Author Addresses, ADSP Discovery SHOULD be
performed independently. This standard will not cover the
consolidation of combined ADSP Discovery results.
3.1. ADSP Discovery Results Usage
A receiving host might obtain varying amounts of useful information
through ADSP Discovery. Such as:
o When a message has a Valid Author Signature, the ADSP Discovery
result is of no benefit since the message is compliant with any
possible ADSP assertion.
o When a message has a Valid Signature that is not also a Valid
Author Signature, the ADSP Discovery result, in conjunction with
the Key Domain of the Valid Signature, is directly relevant to
message assessment.
o When a message is without a Valid Signature, the ADSP Discovery
result at the Author Domain is directly relevant to message
assessment.
3.2. ADSP Discovery Results
Author Domain Signing Practices Discovery at an Author Domain provide
four possible results:
o Message contains an Author Domain that does not advertise
practices.
Otis Expires December 27, 2008 [Page 6]
Internet-Draft ADSP June 2008
o Message contains an Author Domain that advertises practices
indicating they do not ensure messages are initially signed by an
Author Key Domain.
o Message contains an Author Domain that advertises practices
indicating they ensure messages are initially signed by an Author
Key Domain.
o Message contains an Author Domain that advertises practices
indicating they ensure messages are initially signed, and they
recommend dismissing messages not signed by an Author Key Domain.
4. Detailed Description
4.1. DNS Representation
Author Signing Practices records are published using the DNS TXT
resource record type.
NON-NORMATIVE DISCUSSION [to be removed before publication]: There
has been considerable discussion on the DKIM WG mailing list
regarding the relative advantages of TXT and a new resource record
(RR) type. Read the archive for details.
The RDATA for ADSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing
Author Domain Signing Practices. The "Tag=Value List" syntax
described in section 3.2 of [RFC4871] is to be used. Records not in
compliance with that syntax or with the syntax of individual tags
described in Section 4.3 MUST be ignored, although they MAY cause the
logging of warning messages via an appropriate system logging
mechanism. If the RDATA contains multiple character strings, the
strings are to be logically concatenated with no delimiters placed
between the strings.
The ADSP record for an Author Domain is published at a "_adsp."
subdomain directly below the Author Domain; e.g., the ADSP record for
"example.com" would be a TXT record that is published at
"_adsp.example.com". A domain MUST NOT publish more than one ADSP
record; the semantics of an ADSP transaction returning multiple ADSP
records for a single domain are undefined. (Note that "example.com"
and "mail.example.com" are different domains.)
4.2. Publication of ADSP Records
Author Domain Signing Practices are intended to apply to all mail
containing the Author Domain. As a defensive strategy against
Otis Expires December 27, 2008 [Page 7]
Internet-Draft ADSP June 2008
subdomain spoofing, ADSP records can be placed at domains that might
appear to support SMTP.
Wildcards within a domain that is also publishing ADSP records will
not pose a problem. This is discussed in more detail in Section 6.3.
4.2.1. Record Syntax
ADSP records use the "tag=value" syntax described in section 3.2 of
[RFC4871]. Terms used to describe signing practices employ a
metaphor of a door to avoid connotations that might differ from
definitions given in this document.
Tags used in ADSP records are described below. Unrecognized tags
MUST be ignored. In the ABNF below, the WSP token is imported from
[RFC2822]. The ALPHA and DIGIT tokens are imported from [RFC5234].
dkim= practices (plain-text; REQUIRED). Possible values are as
follows:
OPEN (Default) The Author Domain practice permits unsigned
outbound mail.
CLOSED The Author Domain practice always initially signs mail
containing the Author Domain by an Author Key Domain.
LOCKED The Author Domain practice always initially signs mail
containing the Author Domain by an Author Key Domain.
Furthermore, when a message is received without a Valid Author
Signature, receiving hosts are requested to dismiss such
messages.
ABNF:
adsp-dkim-tag = %x64.6b.69.6d *WSP "="
*WSP ("OPEN" / "CLOSED" / "LOCKED")
4.2.2. Author Signing Practices Discovery Procedure
Hosts performing ADSP Discovery should first exclude SMTP clients
with a demonstrated history of abuse. Also, the transactions needed
for ADSP Discovery or DKIM signature validation should be subsequent
to some confirmation that the Author Domain might support SMTP. In
addition, hosts may consider some domains to be exempt, such as Top
Level Domains (TLDs) listed in [RFC2606], for example ".invalid".
[RFC2606] does not represent a comprehensive list of all possible
exempted domains which might also include ".local", therefore,
Otis Expires December 27, 2008 [Page 8]
Internet-Draft ADSP June 2008
appending to a list of exempted domains may be required.
For the purposes of this section, a "valid ADSP record" is one that
is both syntactically and semantically correct; in particular, it
matches the ABNF for a "tag-list" and includes a defined "dkim=" tag.
_ADSP Discovery._ The host SHOULD query DNS for a TXT record
corresponding to the Author Domain prefixed by "_adsp." (note the
trailing dot). The results returned by this operation would be
the value of the "dkim" tag or the value of "MISSING" when none
exist.
NON-NORMATIVE DISCUSSION: Rather than placing ADSP records below the
"_domainkey." prefix used by DKIM, "_adsp." prefixed to the Author
Domain reduces the number of DNS entities needed when ADSP records
are desired at every address record. Delegation of a domain at or
below "_domainkey." and at "_adsp." may be required when
consolidating control of DNS entries related to DKIM.
When any of the DNS transactions involved in ADSP Discovery result in
a temporary error condition, the algorithm terminates without
returning a result; possible actions include queuing the message or
returning an SMTP error indicating a temporary failure.
NON-NORMATIVE NOTE: Within a DNS transaction, as defined by
[RFC1034] section 5.2.2 and [RFC4034] section 3, when a CNAME is
returned, the alias name is to be processed as if it were the
initial name. [RFC2181] section 10.3 makes an exception for
Exchange host names returned by MX records. An Exchange host name
must not return a CNAME.
5. IANA Considerations
ADSP introduces the "_adsp" name into currently unregistered name
space. Although domain names beginning with an underscore will not
collide with host names, service names for [RFC2782] SRV records and
labels for TXT records, defined by other protocols, reference
underscore prefixed names to designate specific use.
INFORMATIVE NOTE [to be removed before publication]: If at the time
of publication no registry has been established or is planned for
underscore prefixed names, this section may be removed.
Otis Expires December 27, 2008 [Page 9]
Internet-Draft ADSP June 2008
6. Security Considerations
Security considerations in the Author Domain Signing Practices mostly
relate to attempts on the part of malicious senders to represent
themselves as sending messages from the Author Domain for whom they
are not authorized to use in their message. This is often done in an
attempt to defraud recipients of the message.
DKIM keys with a restrictive local-part template in the "g=" tag and
value are likely to be employed for untrusted systems that are beyond
the direct control of the Author Key Domain. As a result, additional
care should be taken when a restrictive local-part template does not
match against the Author Address. Signatures, where a restrictive
local-part key "g=" tag and value and the Key Domain do not match
against the Author Addresses, should be considered invalid.
Signatures with restrictive local-part keys where the signing address
is not that of the Author Address will be deceptive when marked as
valid. Recipients are often unaware of the signature's "on behalf
of" identity that is not normally displayed. In addition, these keys
are prone to theft since they are also likely to be used by less
secure mobile users, for example.
Signatures with DKIM keys lacking a restrictive local-part template
are only safely added when the Author Key Domain is able to directly
evaluate signed header fields and content. Recognition of directly
controlled signing improves security in several ways:
Discerns potentially deceptive signatures independent of ADSP
Discovery.
Permits the accurate indication of on whose behalf the signature
was added, even when not on behalf of the Author Address.
Permits the "on behalf of" identity to be derived from an account
instead of being omitted when the Author Key Domain is unable or
unwilling to affirm the identity of the Author Address.
Permits the identity to track either the author or the account
used. This ability can be useful to third-parties who are
attempting to isolate bot-net 0wned systems. In response to a
growing portion of the IP address space being blocked, bot-nets
increasingly send their mail through a provider's outbound server
after obtaining access to valid accounts.
Additional security considerations regarding Author Domain Signing
Practices are found in the DKIM threat analysis [RFC4686].
Otis Expires December 27, 2008 [Page 10]
Internet-Draft ADSP June 2008
6.1. ADSP Threat Model
Email recipients often have a core set of Author Domains that they
trust. Common examples include those of financial institutions with
which they have an existing relationship and Internet web commerce
sites with which they conduct business. DKIM validation and ADSP
Discovery results will not provide any benefit unless receiving hosts
either treat the messages differently during delivery, or provide
some indicator to the end recipient. Such email annotation is out of
scope for this document.
Bad actors often seek to exploit the name-recognition of a trusted
Author Domain. This might be done by just spoofing display-names, or
by placing user local-parts above subdomains or cousin domains in the
From: header field. This problem is made worse by popular MUAs that
do not display actual email addresses. As a result, there is no
empirical evidence showing to what extent unauthorized use of a
domain name contributes to recipient deception, nor that its
elimination will provide a significant effect. Nevertheless, the
automated accrual of behavioural feedback that ignores invalid
identifiers better ensures that systematic confidence is retained for
trusted Author Key Domains.
Training recipients to use automated folder placement could also help
reduce deceptions that utilize domain look-alike and subdomain based
tactics. In addition, automated recognition facilitates optimized
processing by receiver-side message filtering engines that attempt to
curb unauthorized uses of domain names, organizations' names, and
their logos elsewhere within the message. These attacks and their
mitigation are also outside the scope of this document.
The ADSP Discovery algorithm performs one DNS transaction per Author
Domain. Since this transaction, as well as the ones needed to
validate the DKIM signature, are driven by domain names in email
message headers of possibly fraudulent email, receiving hosts
attempting ADSP Discovery and DKIM validation can become participants
in traffic multiplication attacks.
These attacks often target servers consolidating and distributing
behavioral information about bad-actor activities. Such attacks may
dramatically impact the cost of offering the protective service. As
a result, a reduction in number of those offering consolidated
behavioral information places the remaining providers in greater
jeopardy of receiving a larger portion of the abuse.
Otis Expires December 27, 2008 [Page 11]
Internet-Draft ADSP June 2008
6.2. DNS Attacks
An attack might be waged against DNS infrastructure in an attempt to
disable services dependent upon DNS. Such attacks could be made
worse when receiving hosts employ ADSP Discovery and DKIM validation.
A goal to "First, do no harm" is increasingly difficult to achieve
when confronting massive bot-nets. For this reason, SMTP should
consider eventually making MX records mandatory for the acceptance of
public exchanges. The ADSP Discovery process is not expected to
impact the likelihood of an attacker being successful at poisoning
local DNS resolvers. In addition, such DNS security issues are
addressed by DNSSEC [RFC4033].
Although a steady attack may not cause a denial of service, it can
consume significant resources related to "in the cloud" consolidation
and distribution of behavioral information. A typical strategy used
by bad actors employing bot-nets is to rapidly transition from an
active to a dormant state. The duration of activity experienced by
an SMTP server is often brief, and is then followed by a fairly long
dormant period. This tactic proves challenging for defensive
strategies attempted by individual hosts. There is some evidence
that there may be tens of millions of bot-net controlled systems in
the active state, while hundreds of millions appear dormant to
individual SMTP servers.
Consolidating and distributing behavioral information offers
receiving hosts a defensive tactic that can minimize the
effectiveness of the blitzkrieg or fast-flux tactic. Unfortunately,
often part of a bad-actor's strategy is to inundate behavioral
repositories with virtual identifiers. For DKIM, the signature's
identity, "i=" tag and value, and key selector, "s=" tag and value,
can be synthesized since wildcard domain support is possible, unlike
for the Key Domain "d=" tag and value, or the location of the ADSP
record.
Because ADSP operates within the framework of the legacy e-mail
system, the default result in the absence of an ADSP record is for
the Author Domain to be considered "OPEN" where not all messages are
expected to be signed by a Author Key Domain. It is therefore
important that the ADSP clients distinguish a DNS failure such as
"SERVFAIL" from other DNS errors, so that appropriate actions can be
taken.
It is likely that DKIM's and ADSP's combined roles will be to prevent
deception when used in conjunction with automated folder placement of
domains considered trustworthy. To ensure message reception remains
viable for crucial systems when DNS fails, the IP addresses of
crucial SMTP clients should be white-listed. This will allow ADSP
Otis Expires December 27, 2008 [Page 12]
Internet-Draft ADSP June 2008
and DKIM to be selectively bypassed during such events.
6.3. DNS Wildcards
With the exception of wildcard MX records, wildcards within a domain
that also publish ADSP records do not pose a significant problem.
Although referencing SMTP related records will not provide "NXDOMAIN"
results when a domain contains a wildcard, SMTP discovery records,
such as MX or A records, still offer evidence of SMTP support.
Whether AAAA records, absent MX or A records, can be considered
evidence of SMTP support has not withstood widespread use of AAAA
only servers.
NON-NORMATIVE NOTE: Complete ADSP coverage for all subdomains of a
domain remains possible. However, ADSP records would need to be
published at every subdomain containing A records, in addition to
subdomains containing MX records. When SMTP adopts an MX record
mandate for the acceptance of public exchanges, only then could
ADSP records be limited to subdomains containing the MX records.
This strategy would also shelter domains not publishing MX records
from the additional transactions associated with any number of
Author Addresses and DKIM signatures that might be generated per
message.
7. References
7.1. References - Normative
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
Otis Expires December 27, 2008 [Page 13]
Internet-Draft ADSP June 2008
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
7.2. References - Informative
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
(DKIM) Signing Practices Protocol", RFC 5016,
October 2007.
Appendix A. Usage Examples
These examples are intended to illustrate typical uses of ADSP. They
are not intended to be exhaustive, nor to apply to every domain's or
mail system's individual situation.
Administrators are advised to consider the ways that mail processing
can modify messages in a manner that will invalidate existing DKIM
signatures, such as mailing lists, courtesy forwarders, and other
paths that could add or modify headers, or modify the message body.
In that case, if these modifications invalidate DKIM signatures,
receiving hosts will consider the mail not to have a Valid Author
Signature, even though one was present when the mail was originally
sent.
A.1. Single Location Domains
A common mail system configuration handles all of a domain's users'
incoming and outgoing mail through a single MTA or group of MTAs. In
Otis Expires December 27, 2008 [Page 14]
Internet-Draft ADSP June 2008
that case, the MTA(s) can be configured to sign outgoing mail with an
Author Signature.
In this situation, it might be appropriate to publish a "CLOSED" ADSP
record for the Author Domain, depending on whether users also send
mail through other paths that do not apply an Author Key Domain
signature. Such paths could include MTAs at hotels or hotspot
networks used by travelling users, or web sites that provide "mail an
article" features.
A.2. Bulk Mailing Domains
Another common configuration uses a domain solely for bulk or
broadcast mail, with no individual human users, again, typically
sending all the mail through a single MTA or group of MTAs that can
apply an Author Key Domain signature. In this case, before
publishing a "CLOSED" ADSP record, the domain's management should be
confident that all of its outgoing mail will be sent through signing
MTAs. Because it lacks individual users, the domain is unlikely to
participate in mailing lists, but could still send mail through other
paths that might invalidate signatures.
Domain owners often use specialist mailing providers to send their
bulk mail. In that case, the mailing provider needs access to a
suitable signing key in order to apply an Author Key Domain
signature. One possible method would be for the Author Key Domain
owner to exchange keys with the mailing provider. Another would be
for the Author Key Domain to delegate a subdomain below the
"_domainkey." label to the mailing provider. For example,
"bigbank.example.com" might delegate
"esp-00._domainkey.bigbank.example.com" to such a provider. As a
result, the provider could generate keys and DKIM DNS records itself
and thereby provide Author Key Domain signatures.
A.3. Commonly Forged Transactional Messages
In some cases, a domain might sign all its outgoing mail with an
Author Key Domain signature, but prefer that receiving host systems
dismiss mail without a valid Author Key Domain signature to avoid
confusion with mail sent from fraudulent sources that are unable to
apply an Author Key Domain signature. (This latter kind of mail is
sometimes loosely called "forgeries".) In that case, it might be
appropriate to publish a "LOCKED" ADSP record. Note that a domain
SHOULD NOT publish a "LOCKED" ADSP record when it wishes to maximize
the likelihood that its mail is delivered, since it could cause some
fraction of the mail to become rejected or discarded.
As a special case, if a domain sends no mail at all, it can safely
Otis Expires December 27, 2008 [Page 15]
Internet-Draft ADSP June 2008
publish a "LOCKED" ADSP record, since any mail with this Author
Domain would be a forgery.
A.4. Third Party Senders
Another common use case is for a third party to enter into an
agreement whereby that third party will send bulk or other mail on
behalf of a designated Author Domain, using that domain in the
RFC2822 From: or other headers. Due to the many and varied
complexities of such agreements, third party signing is not addressed
in this specification.
Appendix B. Acknowledgements
This document was based upon the draft-ietf-dkim-ssp-003. Dave
Crocker, Frank Ellermann, and Charles Lindsey inputs were valuable.
However, inclusion of their names should not be misconstrued as an
endorsement of this draft. This draft is an individual submission
intended to illustrate a comprehensive solution that might help
foreclose protracted debate when there is otherwise general
agreement.
Appendix C. Update History
C.1. Changes to draft-otis-dkim-adsp-00
o Conditioned Author Signing Practices Discovery Procedure SMTP
verification step to be made only when an MX record had not been
found.
C.2. Changes to draft-otis-dkim-adsp-01
o Modified the Author Signing Practices Discovery Procedure to
better conform with terms in RFC2821. In addition, a note now
covers the issue of CNAMEs.
C.3. Changes to draft-otis-dkim-adsp-02
o Modified the abstract to include the language recommended by Dave
Crocker, clarified the relationship this document has with DKIM,
SMTP and other protocols, and clarified the extent of DKIM
identity parameter. The general language describing the intent
was taken from the WG charter.
o Included non retention of a valid signature and offered an
admonishment to first validate from domain in the introduction.
Otis Expires December 27, 2008 [Page 16]
Internet-Draft ADSP June 2008
o Added a separate definition for Valid Author Signatures by
including the requirement the local-part template must match
against the author addresses.
o Made a few minor changes to the Author Key Domain definition.
o Included the phrase "related to the use of DNS" to the operation
Overview as well as expanding upon the term ADSP Discovery in
several places.
o Modified ADSP Usage to Discovery Results Usage. The information
provided was reorganized from least to most useful.
o Modified the terms in ADSP Discovery Results to be consistent with
advertised practices to align more closely with Dave Crocker's
Abstract.
o The Record syntax now mentions the terms used are a metaphor for a
door, and the terms modified to be in closer alignment with the
abstract.
o The ADSP Discovery procedure now warns about unlimited application
of this process, and suggests some domains may require exemption,
and introduces the term MISSING when no ADSP record is discovered.
o The IANA considerations where shortened based upon the assumption
a registry may not be established for underscore prefixed TXT
records.
o Change the beginning of the security section to clarify the domain
and not the author identity is assured by DKIM and ADSP.
o Changed the wording related to the key "g=" parameter to be more
consistent throughout the document.
o Mention in the threat model annotation is required, but is out of
scope.
o Modified the paragraph that describes exploitation of trust to be
about the domain and not the author identity.
o Mention that the target of an attack is often directed to
behavioral information services.
o Add paragraph describing the typical nature of bot-net behaviour,
and how the DKIM "i=" represents a significant vulnerability for
the accrual of behavioral information.
Otis Expires December 27, 2008 [Page 17]
Internet-Draft ADSP June 2008
o Add a sentence to highlight benefits using automatic folder
placement.
o Expanded the DNS wildcard section to generally describe what might
be involved when validating the domain's support of SMTP.
C.4. Changes to draft-otis-dkim-adsp-03
o Clarify the definition of signing address when used in conjunction
with restrictive local-part templates by adding a paragraph to
Section 2.1.
o Modified the list in Section 3.2 to include the case where the
Author Domain has no ADSP record.
o Give examples in Section 4.2.2 regarding possibly exempt TLDs.
o Expand upon the recognition of direct versus indirect control of
the DKIM signing process, and how this relates to the use of the
"on behalf of" identity by adding two paragraphs to Section 6.
o Made several minor grammatical changes.
Author's Address
Douglas Otis
Trend Micro, NSSG
10101 N. De Anza Blvd
Cupertino, CA 95014
USA
Phone: +1.408.257-1500
Email: doug_otis@trendmicro.com
Otis Expires December 27, 2008 [Page 18]
Internet-Draft ADSP June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Otis Expires December 27, 2008 [Page 19]
