| TOC |
|
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 February 9, 2009.
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) defines DNS records that advertise the extent to which a domain employs [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) to sign [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) messages, and how other hosts access these advertisements. The goal is to control the use of From header field. When a message is not adequately signed, advertised assertions referenced by a domain in the From header field assist in resolving the message's intended disposition.
However, [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) fails to discern that when restricted identities are imposed upon remote signing agents, additional controls must be afforded the domain in this case. The draft also ignores the predominate role of the domain, and assumes the signature always makes assertions regarding the identity of the author, which ignores safety and goes well beyond the charter. In addition, the only directly actionable practice is defined using a term likely to negatively impact the integrity of delivery status as well.
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) impairs security in other ways, but fortunately minor changes to the definition of a valid signature can significantly remedy the most critical security issue.
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.).
1.
Introduction
2.
Recommended Changes
2.1.
3.2 ADSP Usage
2.2.
2.7. Author Signature
2.3.
Section 4.1. DNS Representation
2.4.
3.1. ADSP Applicability
2.5.
4.2.1. Record Syntax
3.
IANA Considerations
4.
Security Considerations
4.1.
Considerations not managed by draft-ietf-dkim-ssp
5.
References
5.1.
References - Normative
5.2.
References - Informative
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
Both [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) and [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) lack a general requirement for signatures using keys restricting the remote signing agent's "on-behalf-of" identity signing that would compel the identity to also match against the From header field for the signature to be considered valid. [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) makes a statement that is emblematic of how the signature's role can be distorted. This statement can not be applied at message acceptance, does not acknowledge restricted identities for remote signing agents need to be afforded greater control by the domain, ignores the predominate role of the domain, but instead assumes the DKIM signature's predominate role is to make assertions regarding the identity of the author. In section 6.3 paragraph 5,
- "If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader."
At best, DKIM might make weak assertions regarding the identity of the author, however lacking a wide range of supporting conventions, reliance upon such assertions is not safe. Whether the signature is valid must remain clear to sustain delivery integrity, but not the "on-behalf-of" identity when the key provided the signing agent can be used to sign on behalf of the entire domain. Signing agents afforded unrestricted keys should be considered to have applied policy against the entire message. The trust establish is with the signing domain, and can never be based upon a dubious identity within the From header field.
Detecting inappropriate use of a identity restricted key should occur quickly and prior to message acceptance. This can be accomplished without verifying the signature. The intent would be to preclude acceptance of messages that make an unverifiable use of a domain within the From header field, and not have this check prefaced by the domain also advertising their practices.
The [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) requirements affect messages that lack signatures, or where the From header field address is not within the signing domain, or where the "on-behalf-of" identity does not match against the From header field. However, the impact of the "on-behalf-of" identity requirement only occurs when restrictive practices are advertised, irrespective of the type of key used. This creates a security vulnerability that may encourage DNS attack, and unnecessarily limits the practical utility of the DKIM signature.
The "on-behalf-of" identity constraint ignores the signing domain's role and its need for comprehensive control over the From header field whenever identity restricted keys are used by remote signing agents. When a key used by a signing agent restricts the "on-behalf-of" identity, ignoring that this identity fails to match against the From header field ends up imposing practical limitations and reduces delivery integrity. Initially ignoring the failure affects all signing agent's ability to then indicate for whom or for what their signature was added, whenever a failure to match is then tested at subsequent stage where the nature of the identity has not been retained.
When such a restricted identity failing to matching against the From header field is considered to provide a valid signature, but is then subsequently invalidated when an advertisement by the domain is discovered, the two stage conditional requirement is likely to be applied unnecessarily against all signing agents. When the basic status of signature validity is dependent upon the success of advertisement discovery, such a two stage process is likely to negatively impact both delivery integrity and security. Limitations imposed on the "on-behalf-of" identity within the second stage alters the freedoms established by [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.), and is wholly without merit.
To control remote signing agents, keys may restrict "on-behalf-of" identity signing. However [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) imposes no requirement for restricted identity placement within the message. In addition, [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) incorrectly assumes reliable advertisement discovery, and otherwise fails to impose restricted identity placement as well. Although remote signing agents may have keys that restrict identity signing, the domain is unable to control whether a restricted "on-behalf-of" identity also matches with the From header field.
For [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.), the "on-behalf-of" identity is not required to be that of a message author, and may even indicate the authentication of a system or an access account. This distinction is important since predominately compromised systems, rather than individuals, are the source of abuse. Unfortunately, [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) places constraints on what may be placed within the "on-behalf-of" identity.
Receiving hosts verify a DKIM signature by obtaining the corresponding public key. A valid signature confirms the message is attested to by a party in possession of the private key, and in control of a portion of the domain publishing the public key. An important additional consideration must be applied whenever a key restricts the "on-behalf-of" identity for remote signing agents. For the domain to control the From header field, a restricted "on-behalf-of" identity must then be required to also match against the From header field before the signature is considered valid at any point in the process.
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) should only introduce restrictive practices that ensure the From header field domains are within their signing domain, and ensure the signing domain is able to control the From header field for remote signing agents in all cases. From a security standpoint, it would be dangerous for [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) or [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) to suggest a valid signature asserts the identity of the author. There are no conventions where such an assertion has a safe basis and goes well beyond the charter.
Keys that restrict the "on-behalf-of" identity being signed are likely employed by mobile users having limited access to the domain's outbound signing servers. In the case of a key restricted identity, the signature is required to include a matching identity. Currently there is no general requirement that the restricted identity also match against the From header field. Since these keys are prone to theft and are easily abused, no signature should be generally considered valid when a restricted identity does not match against the From header field.
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) fails to stipulate that signatures for identity restricted messages should be considered invalid when the identity does not match against the From header field. These signatures are only considered invalid when the domain is able to advertise a restrictive practice. For security reasons, ensuring that a restricted identity match against the From header field must not depend upon a fragile DNS mechanism and a domain's ability to use a restrictive advertised assertion. The concern becomes even more paramount when restrictive advertised assertions potentially harm the integrity of the delivery status and are thereby avoided.
As IP addresses are increasingly being blocked, compromised systems, which often contain account information, frequently are used to gain access to larger domains where blocking their messages typically proves impractical. Ordinarily, larger domains are either unwilling or unable to affirm the identity in the From header field and end up leaving the "on-behalf-of" identity tag and value blank. The limitation induced by [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) ensures it will remain impractical for the "on-behalf-of" identity to always indicate what had been authenticated as might be needed to ensure security, and as intended in [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.).
Ironically, an ability to always indicate an authenticated identity was lost due to an optimization that considered signatures having a restricted "on-behalf-of" identity not matching against the From header field to be valid. Any scheme that considers signatures valid when a restricted identity does not match against the From header field places recipients in significant peril since the signature header or this identity is seldom visible and leaves the From header field open to exploitation.
| TOC |
| TOC |
CHANGE:
If a message has a Valid Signature from an Author Domain, ADSP provides no benefit relative to that domain since the message is already known to be compliant with any possible ADSP for that domain.
TO:
If a message has a Valid Signature from an Author Domain, an additional consideration must be applied. When a key used to validate the signature imposes a restrictive template on the local-part of the "on-behalf-of" identity, this template and the signature's domain should also match against an address contained within the From header field, or the signature should not be considered valid.
A match is determined by construction of a template composed of the key's
"g=" tag and value, and the domain as denoted in the signature's
"d=" tag and value in the form:
- <g value | * >@[*.]<d value>
The default for the key's local-part template value, when it is not present, is "*", in which case no From header field comparison will be required.
| TOC |
CHANGE:
An "Author Signature" is any Valid Signature where the identity of the user or agent on behalf of which the message is signed (listed in the "i=" tag or its default value from the "d=" tag) matches an Author Address in the message. When the identity of the user or agent includes a Local-part, the identities match if the Local-parts are the same string, and the domains are the same string.
TO:
An "Author Signature" is any Valid Signature per section 3.2, where an Author Address domain is within the signature's "d=" tag and value domain.
| TOC |
CHANGE:
_adsp._domainkey.
TO:
_adsp. (preferably adopt a specific resource record instead).
| TOC |
CHANGE:
ADSP as defined in this document is bound to DNS.
TO:
ADSP as defined in this document is bound to DNS and SMTP.
| TOC |
CHANGE TERMS:
Discardable and discard
TO:
Dismissable and dismiss
- Even for the example cases sighted, arrangements are being made to offer feedback to determine the level of abuse. The term discardable is likely to thwart adoption when the integrity of the delivery status is also important. If the mechanism proves effective, the level of abuse should also dramatically wane.
| TOC |
This document requires no IANA consideration.
| TOC |
| TOC |
DKIM keys with a restrictive local-part template in the g= tag and value are likely employed by remote signing agents beyond the direct control of the signing domain. As a result, additional consideration is required when a restrictive local-part template does not match against the From header field. Signatures should not be considered valid whenever a restrictive local-part key g= tag and value, and the signature d= tag and value, do not match against a From header field address.
Signatures by keys lacking a restrictive local-part template are only safely used when the signing agent is able to directly evaluate the signed header fields and content. Recognition of signing agents able to apply policy over the entire message improves security in several ways:
- Discerns potentially deceptive signatures independent of advertised signing practice discovery.
- Permits an accurate indication of on whose behalf the signature was added, even when not on behalf of the author's address.
- Permits the "on behalf of" identity to be derived from an account instead of being left blank when a signing domain is unable or unwilling to affirm the identity of the author's address.
- Permits the identity to track either the author or the account used. This ability can be most useful to third-parties that attempt 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.
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) should state a valid DKIM signature does not safely provide an assertion of the author's identity, and that only the domain contained within the signature will have been verified by DKIM signature validation. In addition, when the "on-behalf-of" identity signing is restricted, and does not match against the From header field, the signature should not be considered valid.
| TOC |
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) fails to signal which transport protocol implements an advertised practice. As such, it also fails to indicate which DNS resource, if any, supports the transport. Although verifying a domain's existence might query resource records specified by [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.), the associated transport is never specified, where only query errors returned are meaningful.
Since the goal is to control use of a domain in the From header field, a DNS error will then likely require a message to be refused, since the proposed methods are unable to resolve practices over a domain hierarchy. [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) also never specifies a transport or related resource records. This means any wildcard resource record within the domain will thereby allow domain spoofing. Any domain using wildcards will permit any synthesized domain appear to lack advertised practice assertions.
Contrary to the MUST NOT use wildcards mandate, a solution for covering the entire domain hierarchy or to cope with wildcard resources will likely be wildcard TXT resource records containing restrictive practice assertions. The sanctioned alternative would be to publish separate resource records at each existing domain node. As if a per node alternative was not bad enough, this alternative has been made even less attractive by requiring more entries and by consuming more resources than otherwise required.
The additional DNS overhead occurs with the use of two prefixed subdomain labels locating the TXT resource record. Instead of just the 6 byte "_adsp.", the additional "_domainkey." label introduces an additional 11 bytes and subdomain for every DNS node protected. Justification for having any label was to accommodate typical web-based commodity provider tools that often do not support new resource record types.
Justification for the second label is likely based upon a false assumption that delegation of the "_domainkey." subdomain will also facilitate the typical needs of third-party providers expected to advertise practices at just the domain supporting the transport.
There are transport protocols in wide use that employ [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) messages, but that might not utilize DNS. There are also cases where a domain contained within a message is intentionally not found in DNS. Such domains may deal with a different name space, or ensure the related address is not exploited by spammers. [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) does not offer a means to deal with messages that conflict with a strategy that depends upon the lack of DNS errors as a basis for acceptance.
[I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) should recommend that recipients be advised to use automated folder placement for trusted signing domains to reduce deceptions that utilize domain look-alike and subdomain based tactics.
| TOC |
With the exception of wildcard MX records, wildcards within a domain that also publish ADSP records should 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.
For security reasons, SMTP should also adopt an MX resource record mandate for the acceptance of public exchanges. This would then mean advertised practice discovery could be limited to subdomains containing MX records, and ensure failure of a single transaction obtaining an MX record would curtail all other message related transactions. An MX resource record mandate would thereby shelter domains not publishing MX records from the additional assortment of transactions often associated with any number of spoofed email-addresses and DKIM signatures that might be generated per message.
| TOC |
| TOC |
| [I-D.ietf-dkim-ssp] | field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” draft-ietf-dkim-ssp-10 (work in progress), May 2009 (TXT). |
| TOC |
| TOC |
| Douglas Otis | |
| Trend Micro, NSSG | |
| 10101 N. De Anza Blvd | |
| Cupertino, CA 95014 | |
| USA | |
| Phone: | +1.408.257-1500 |
| Email: | doug_otis@trendmicro.com |
| TOC |
Copyright © 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.
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.