DKIM Author Domain Signing Practices (ADSP) Security Issues

Both and would benefit from a general 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. 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. To sustain delivery integrity, whether the signature is valid must remain clear. The "on-behalf-of" identity may 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 establish 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. An important missing check is needed to repair . The check should be applied whenever a key restricts the "on-behalf-of" identity for remote signing agents. For the domain to control the From header field with remote signing agents, a restricted "on-behalf-of" identity must then be required to also match against the From header field before considering the signature to be valid. The From header field requirement for a restricted "on-behalf-of" identity should be consistent at every stage in the process. Ideally, should only introduce 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. 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 "on-behalf-of" 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 considered valid when a restricted identity does not match against the From header field. fails to stipulate that signatures using identity restricted keys 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 at the domain or subdomain in question. Ensuring that a restricted identity match against the From header field should not depend upon the recipient discovering and the domain being able to assert a restrictive advertised practice. Not relying upon restrictive advertised assertions becomes even more paramount when the restrictive advertised practices potentially harm the integrity of delivery status. When delivery integrity is important, restrictive advertised practices may need to be avoided. As IP addresses are increasingly being blocked by providers, compromised systems, often containing account information, are frequently used by bad actors to gain access to larger domains, where blocking the combined outbound messages often prove impractical. Ordinarily, larger domains are either unwilling or unable to affirm the identity in the From header field and, as a result, may end up leaving the "on-behalf-of" identity tag and value blank. The constraints imposed by makes it impractical for the "on-behalf-of" identity to always indicate what was authenticated, as intended in . 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 to be 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 are seldom visible, and this leaves the From header field open to exploitation. Detecting inappropriate use of an identity restricted key should occur quickly and prior to message acceptance. The fix for is to preclude signatures from being considered valid that might permit an unverifiable use of a domain within the From header field by remote signing agents. This check is not prefaced upon first discovering whether the domain advertises practices. In other words, in addition to restrictions on the "on-behalf-of" identity within the signature for remote signing agents, the From header field should also match against the same restriction. Currently, 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. When a restricted identity fails to match against the From header field and is considered to provide a valid signature, may subsequently invalidate the signature whenever a practice advertisement by the domain is discovered. Unfortunately, the two stage conditional valid signature requirement unnecessarily affects all signing agents. Signature validity is 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 . When the signing agent employs unrestricted keys, this change is wholly without merit. To control remote signing agents, keys may restrict the "on-behalf-of" identity being signed. However imposes no requirement for restricted identity placement within the message. In addition, incorrectly assumes reliable advertisement discovery, and fails to impose restricted identity placement for remote signing agents 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 is also assured to match with the From header field, except by publishing advertised practices at every existing subdomain. For , the "on-behalf-of" identity is not required to be that of a message author, and may even indicate 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, places constraints on what may be placed within the "on-behalf-of" identity. It is unrealistic to suggest multiple signatures offer a solution, since this doubles the related overhead. 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.

Section 3.2 of 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 Author Signatures, 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 will not impose this limitation, where the Author Signature requirements therefore 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 . 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 lacking identity restrictions, clearly indicates that the signature was applied by a trusted signing agent. A trusted signing agent can sign on behalf of the entire domain, and should first ensure message conformance prior to signing. A signature by the Author domain using a key that lacks identity restrictions is sufficient to ensure a domain's ability to control the use of the From header field, and to assert any sundry list of message conformance requirements. A valid signature applied using a key lacking identity restrictions by the Author Domain 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.

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 assessment could lead to interchange problems when only a portion of the possible related transports employ . Omitting public transport specifics might seem reasonable, since there are many possible protocol gateways into SMTP provided by various third-parties. Remaining silent on the relevant transport will lead to various ad-hoc methods for dealing with protocol gateways. The omission fails to warn of potential problems, such as various news articles being dropped, for example. Omitting transport specifics has lead to the general requirement in Section 4.3 that any ADSP related transport use DNS at the domain of the address. The lack of transport agility is the result of there not being any ADSP parameter that makes any specific public transport assertion.

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 the 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.

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.

CHANGE: _adsp._domainkey. TO: _adsp. (preferably adopt a specific resource record instead).

CHANGE: ADSP as defined in this document is bound to DNS. TO: ADSP as defined in this document is bound to DNS and SMTP.

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.

This document requires no IANA consideration.

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. 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.

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 , 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. 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 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. 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.

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.

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.