| 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 April 4, 2009.
The proposed [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 defines how other hosts can access these advertisements. Its laudable goal is to allow domains control over the use of the 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.
Rather than dealing with keys that impose a restriction on the "on-behalf-of" identity as a separate security consideration to be handled independently from an assertion that a domain signs their messages, [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.) instead employs a flawed two-stage signature validation process that works in conjunction with advertised practices. The two-stage approach will most likely occur after message acceptance, and impairs the range of authentication assertions permitted by a single signature. The limitations on authentication assertions inhibits tactics needed to deal with replay abuse.
As currently structured, advertised practices not only assert whether a signature should be expected, they also constrain the "on-behalf-of" identity applied by signing agents that are not otherwise so restricted by [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.). By constraining the "on-behalf-of" identity for all signing agents, the draft neglects the predominate role of the domain as a point of trust, and incorrectly assumes the signature is limited to supporting assertions regarding the identity of the author. By limiting the DKIM signature's "on-behalf-of" value to being representative of only the message's author, the draft goes well beyond the working group's charter and appears to infringe on S/MIME's and OpenPGP's role.
[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 as well, such as the only directly actionable practice is defined using a term likely to negatively impact the integrity of delivery status. Fortunately minor changes to the definition of a compliant signature can remedy the impairment created, where the critical security issues are best handled independent of any [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.) assertion.
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.
Imparing DKIM Signature's Utility
3.
Errors and Omissions
3.1.
Factual Errors
3.2.
Factual Omissions
4.
DKIM and SMTP's transition to IPv6
5.
Recommended Changes
5.1.
2.7. Author Signature
5.2.
Section 4.1. DNS Representation
5.3.
3.1. ADSP Applicability
5.4.
4.2.1. Record Syntax
5.5.
6. Security Considerations
6.
IANA Considerations
7.
Security Considerations
7.1.
Considerations not managed by draft-ietf-dkim-ssp
8.
References
8.1.
References - Normative
8.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.) would benefit from a general security requirement for signatures with keys that restrict a remote signing agent's "on-behalf-of" identity, where this identity must also match against the From header field before being considered valid. This change to the definition of a valid signature would significantly remedy what is likely to become critical security issues, but this check should be independent of the ADSP assertions.
[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 as a basis for message acceptance, does not acknowledge that restricted identities for remote signing agents require greater control be afforded the domain, and ignores the predominate role of the domain by assuming the DKIM signature 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 a weak assertion regarding the identity of the author. However, these assertions lack a wide range of supporting conventions where reliance upon an author identity would be unsafe. For example, ancillary Display Names are not controlled by the signing domain when remote signing agents are used.
To sustain delivery integrity, whether the signature is valid must remain clear. There is no reason why the "on-behalf-of" identity can not be opaque whenever the key employed by the signing agent can sign on behalf of the entire domain. Signing agents, afforded unrestricted keys, can be considered able to verify the entire message's compliance with the domain's practices. The established trust is with the signing domain, and can never be based upon a dubious identity within the From header field.
Conceptually, 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. Ideally, [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 practices that ensure the From header field domains are within their signing domain.
As providers block SMTP's public port 25 for a growing number of IP addresses, compromised systems, often containing account information, are prevalently being used by bad actors to gain access to larger domains. Blocking the combined outbound messages from larger domains often proves impractical. Ordinarily, larger domains are either unwilling or unable to affirm the identity in the From header field and, as a result, end up leaving the "on-behalf-of" identity tag and value blank. Leaving the identity tag value blank severely limits a recipient's defence against replay abuse, and as such, should be considered a bad practice. The "on-behalf-of" identity tag and value should always reflect the element authenticated, even when this value is opaque and dynamic.
The constraints imposed 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.) make it impractical for the "on-behalf-of" identity to always indicate what was authenticated, 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 as a result of optimizing a two-stage signature validation scheme that considered signatures with a restricted "on-behalf-of" identity that does not match against the From header field, to be initially valid. Schemes that consider signatures valid when a restricted "on-behalf-of" identity fails to match against the From header field places recipients in significant peril. Signature headers, which are seldom visible, contain the "on-behalf-of" identity. Any annotation or handling of these signatures as being valid, that also have a restricted "on-behalf-of" identity that does not match against the From header field, would leave the From header field open to exploitation.
Detecting inappropriate use of an identity restricted key should occur quickly and prior to message acceptance. Based upon independent security considerations, signatures using keys that impose restrictions upon local-parts that fail to match against the From header field should not be treated as a valid signature. This check must not be prefaced upon discovering whether the domain advertises practices. In other words, in addition to keys placing restrictions upon the "on-behalf-of" identity within the signature for remote signing agents, the From header field should also match against the key's local-part restrictions as well.
Currently, [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.) advertised practices may 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. The impact of an advertised practice and the resulting "on-behalf-of" identity requirement occurs irrespective of the type of signing agent and key used. This creates a security vulnerability that may encourage DNS attack, and unnecessarily limits the practical utility of the DKIM signature. A massive dispersal of spoofed messages is likely able to defeat an advertised practice whenever there is an intervening DNS resolver between the recipient's MTA and the signing domain's name server.
Unfortunately, the two-stage conditional valid signature requirement imposed 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.) unnecessarily affects all signing agents. Signature validity becomes dependent upon the success of advertisement discovery, where this 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 may alter what is considered valid by [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.). When the signing agent employs unrestricted keys, this change is wholly without merit. This also means that a domain is not assured that a restricted "on-behalf-of" identity that does not match with the From header field will be considered invalid, except by publishing advertised practices at every existing subdomain.
Per [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. It is unrealistic to suggest the impractical use of multiple signatures as a solution, since this doubles the overhead related to signatures and signature validation. [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) has already defined an "on-behalf-of" identity. There is no reason to reinvent the meaning of the "on-behalf-of" identity in support of a flawed, two-stage, conditional, valid signature definition.
| TOC |
The DKIM WG mailing list provides little insight as to why factual errors and security concerns were not fully discussed, or why a safer, simpler, and more compliant valid DKIM signature definition wasn't accepted. Perhaps the only remaining consideration is whether the WG has unsafely exceeded their charter.
The charter states:
- The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain.
- ... To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include:
- * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users).
- * Duplication of prior work in signed email, including S/MIME and OpenPGP.
One will not find an explanation as to why a signature's "on-behalf-of" value must match against an email-address found within the From header field, or that it be left blank to be compliant with an ADSP message signing assertion.
Why isn't it enough to ensure that a message was directly signed by the From domain, as suggested in [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.) Section 3.2? Why should a recipient consider signatures to be valid when a local-part restricted by a key fails to match against a From email-address? The errors and omissions in [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.) are not harmless and will significantly weaken both the utility and security of DKIM signatures.
The current Author Signature definition inhibits:
If differentiating between remote and direct signing agents is considered outside of the charter's scope, then [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.) section 2.7 and sections 4.2.1 Record Syntax definitions that depend upon an "Author Signature" exceed this charter to an even greater degree.
The motivation for the current draft likely results from larger domains protecting their ability to limit recipients to an "all-or-nothing" acceptance of their messages. The recommended changes do not require that a non-blank "on-behalf-of" be used. However, these changes allow a practice that always offers recipients a means to differentiate between opaque sources internal to the signing domain.
Asserting the "on-behalf-of" as an opaque value that correlates with what the domain authenticated is a reasonable use of the "on-behalf-of" value, since such information offers a defence against possible replay abuse. From the larger domain's perspective, recipients basing acceptance upon the signing-domain and "on-behalf-of" as an authentication token will be placing smaller domains on an equal footing. The increased granularity afforded by the "on-behalf-of" value thereby mitigates the influence that a large domain would have in coercing acceptance of their domain's messages.
Larger domains are currently able to send a fair amount of spam without much risk of being blocked. The level of this spam is rising, where a greater tolerance to this spam is necessitated. As a result, large providers are able ignore a spam problem when it represents a source of revenue or when dealing with the source incurs support costs. Although the changes to ADSP being recommended will not prevent large domains from continuing to use blank "on-behalf-of" in their signatures, this strategy is much more likely to be considered a bad practice in the future.
The charter correctly excludes attempts to transform DKIM into being a scheme that affirms the identity of the author. This limitation was prudent since DKIM does not control the Display Name, and does not ensure which, if any, header field corresponds with the "on-behalf-of" identity. By adopting the recommended changes, it is more likely that a compromised system of a user will cause them to receive error messages that indicate that their system appears to be compromised. The use of opaque "on-behalf-of" values allows the signing domain a means to modify the token and unilaterally redeem the account without needing to change their email-address.
The typical abuse driving demand for [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.) has been the flood of phishing attempts. ADSP should permit more stringent filtering based upon message content that fails to correlate with a From header. However, the Author Signature definition is unlikely to play a significant role in this effort.
| TOC |
| TOC |
Section 3.2 of [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.) makes a factual error in stating that a valid signature by an Author Domain is already known to be compliant with any possible ADSP for that domain. Compliance with ADSP currently requires an Author Signature, not just a signature by the Author domain.
The Author Signature requires the "on-behalf-of" identity to match against the author's address. A valid signature by the Author Domain per [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) will not impose this limitation, where 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.) Author Signature requirements limit interchange without justification.
For example, office administrators might submit messages authored by their managers. The authenticated DKIM signature "on-behalf-of" identity could be that of the office administrator whose email-address was placed within the Sender header field as permitted by [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.). When a signing domain's practice permits office administrators to send messages on behalf of managers, a manager's email-address could be placed within the From header field to signify the manager's role as author.
A valid signature, verified with a key that lacks identity restrictions, clearly indicates the signature was applied by a trusted signing agent. A trusted signing agent can sign on behalf of the entire domain and should ensure message conformance prior to signing. A signature by the Author domain, with a key that lacks identity restrictions, is sufficient to ensure the domain's ability to fully control the use of the From header field, and to assert any sundry list of message conformance requirements.
A valid signature applied by the Author Domain using a key that lacks identity restrictions should be considered compliant with any possible ADSP. However, the current Author Signature definition, in conjunction with the discovery of a practice, may cause a valid signature to become invalid when assessing ADSP compliance where the "on-behalf-of" identity does not match against the author's address. This restriction would only have merit in the case of a local-part restricted key, but this security consideration should be made in this instance irrespective of any ADSP assertions.
To be in strict compliance with the WG charter, the issue of remote signing agents can be ignored as something that is self-evident based upon the key information and the From header field content. A recipient should always deal with this concern as a separate issue unrelated to whether a message should have been signed.
| 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.) attempts to define practices used by a domain, but then fails to specify which public transport protocol or protocols meet the advertised practice. Misapplication of practice compliance assessments could lead to interchange problems when only a portion of the possible [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) related transports employ [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.).
Omitting public transport specifics might seem reasonable, since there are many possible protocol gateways into SMTP provided by various third-parties. However, remaining silent on the relevant transport will lead to various ad-hoc methods for dealing with protocol gateways. As a result of the omission, [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 warn of potential problems, such as various NNTP messages being dropped, for example.
Omitting transport specifics has also lead to the general requirement in [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.) Section 4.3 that any ADSP related transport will use DNS at the domain of the address. A lack of transport agility results from there not being any ADSP parameter that makes a specific public transport assertion to clarify where and what resources are available. The positive identification of DNS resources would be essential for determining whether a domain in question is within scope of the ADSP compliance requirements. Unfortunately, ADSP is structured to expect the existence of any DNS resource in determining the acceptance of a message that is not already in compliance with any possible ADSP.
| TOC |
As IPv4 addresses become less available, a demand is growing for the acceptance of IPv6 SMTP clients over port 25. IPv6 supports 340,000 decillion (340,000 x 10^33) unique addresses that operate over dual-stacks, IPv6/IPv4 gateways, and tunnels. Currently, protective services defend MTAs from abusive clients by processing logs that resolve on the order of 200 million unique IPv4 addresses every few minutes. These protective services are time sensitive while providing a dynamic shield against sporadic, and often high levels of abuse, when these sources are aggregated.
The resources consumed, and cost expended, in providing protective services is not insignificant. A desire to use IPv6 addresses with SMTP happens at a time where companies are striving to reduce their expenditures. There is some justification in cutting back on SMTP specific protections. Surveys indicate email represents a small and falling percentage of one's direct exposure to malware. The browser, rather than the MUA, offers a greater target of opportunity for bad actors.
Although DKIM has a potential for replay abuse, combining the signing domain with the "on-behalf-of" identity can better establish a defensible basis for acceptance, as opposed to a virtually unlimited IPv6 address space that is also more likely to represent a mixture of good and bad actors. Using the DKIM domain and "on-behalf-of" identity tuple to tracking tens of millions of opaque accounts within hundreds of thousands of large domains represents a manageable dataset of about 6 billion.
This dataset represents an increase of about 30,000 times over the dataset now defending IPv4. Even with this sizable increase, DKIM still offers a simpler, more reliable, more effective, and much smaller dataset than what is likely needed to track a more complex range of IPv6 addresses that extend well beyond a human comprehensible scale.
For DKIM to provide a defensible basis for acceptance, the signing domain needs to offer valid "on-behalf-of" identities that track the elements authenticated by the signing domain. A domain, that can be trusted to offer opaque identifiers of what they authenticate, provides a safe basis for acceptance. These identifiers might represent that of an account, an IP address within a network, or a system's certificate, and not that of an email-address found within the From header field.
Most abuse is enabled by compromised accounts or systems that are seldom directly associated with a From email-address. Since ADSP is unlikely to alter what a domain authenticates, DKIM can be far more effective against abuse wrought by compromised systems by allowing the "on-behalf-of" identity to represent an account or system as well. 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.) requires a bad practice where the "on-behalf-of" must be blank when it does not represent that of the From header field. The imposition of a bad practice results from the failure of [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 differentiate between remote and trusted signing agents. [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.) prevents the good practice of always indicating the element authenticated. [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 fails to satisfy a goal of controlling the From header field when remote signing agents are used.
| TOC |
| 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).
- There is no practice that asserts no email is signed, so the presence of the "_domainkey." subdomain at every existing node creates a misleading appearance of DKIM support at each node. The absence of the "_domainkey." subdomain clarifies that the domain does not support DKIM.
| 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 in the DKIM mailing list, arrangements are being made to offer feedback to the sender so they can 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 |
Consider appending portions of this draft's Security Considerations.
| 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 to be 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. 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. Being able to track the element granted access by a domain is most useful to third-parties wanting to implement a safe basis for refusing problematic accounts. Blocking problematic accounts will likely isolate bot-net 0wned systems.
A valid DKIM signature does not safely provide an assertion of the author's identity, and 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 returned query errors 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, because 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 the related resource records. This means any wildcard resource record within the domain will thereby allow domain spoofing. Any domain that uses 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 for coping 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 is made even less attractive by requiring more entries and by consuming more resources than otherwise required had a specific resource record been defined for ADSP, or had just a single prefix been used.
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. The logic 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 the delegation of the "_domainkey." subdomain will also facilitate the typical needs of third-party providers that advertise practices at only the domain supporting the transport. Use of the "_domainkey." subdomain for placement of ADSP resource records also makes it impossible to ascertain whether the domain might have generated a signature that can not be verified.
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 be used to deal with a different name space, or to ensure the related email address is not exploited by spammers. Without any transport or related resources being defined, [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 offer a practical a means to deal with messages that might conflict with its strategy that depends upon the lack of DNS errors as an implied 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 the 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.