DKIM Security Concerns
draft-otis-dkim-security-concerns-01

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 September 27, 2009.

Abstract

This document describes a few security concerns remaining within the working group draft of the DKIM base document. As the base document is a work-in-progress, some issues may have been already resolved. As with many protocols, accommodations for convenience are balanced against possible negative security repercussions. This draft attempts to expand upon some of these repercussions. In addition, some threat scenarios may have been considered too improbable to warrant the inclusion of mechanisms exceeding prior strategies. This draft attempts to justify added precaution. And lastly, some considerations may have neglected a transformation occurring with the display of the email-address localpart and domain impacting a recipient's recognition. This draft offers minor remedies for these security related issues.

Table of Contents

1.  Introduction
    1.1.  What to trust?
    1.2.  When Things Go Wrong
2.  Definitions
3.  Deprecated Versions
4.  Questionable Provisions for 2048bit Keys
5.  Email-Address Validation
6.  Use of Fabricated Subdomains within DKIM Identity Validations
7.  Deletion of Invalid Signatures
8.  Email-Address Recognition Option
9.  Opaque-Identifier Option
10.  IANA Considerations
11.  Security Considerations
12.  References
    12.1.  Normative References
    12.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The current DKIM base document [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” February 2007.), has made significant improvements over previous versions, where only a few issues remain that can be remedied with fairly minor changes recommended in this review. Some options such as the Reliance Level and Opaque-Identifier options have been included only to provide a more complete picture of possible follow-on efforts.

The foot-hold email provides criminal elements must be changed to reduce the damages being wrought. Controlling this damage might be achieved, but only at the level of the largest denominators, where authentication is required for this control to be meted out fairly. DKIM assures that only the signing domain is authenticated, and that is exactly what is needed. However, DKIM will not reduce the tide of abusive messages.

1.1.  What to trust?

DKIM will allow recipients to know, based upon the signing domains, what can be trusted. Recognition of an email-address, or relianance upon there being imposed restrictions on the use of an email-address is never assured. Signing domains used in conjunction with a comparison made against a recipient's "trusted" list will go a long way toward removing the criminal foot-hold. Since control must be at the signing domain, so must be the trust.

While implicitly restricting the use of an email-address is within the current base draft, this approach overlooks a myriad of exceptions and disruptions email-address use restrictions will create. Without any message annotation in place, a reduction in the spoofing of common transactional messages can be achieved by a process that compares message content with that of the signing domain. Unless explicitly assured and so annotated, this comparison might actually ignore the originator's email-address, which often is not fully visible. Other message content composed of images and links are items likely forming a basis for recipient recognition and provides greater cause for rejection.

While some expect acceptance criteria offers protection, message annotation is safer, more effective, and proactive. Satisfying restrictive criteria placed upon email-address use will be readily achieved by those wishing to establish an illusion of accountability. In addition, their domains will vary frequently and are likely purchased with stolen credit. No recipient can be expected to reliably recognize an email-address, see DKIM related headers, and visually confirm the validity of a signature. Restrictive email-address comparisons as a basis for acceptance will cause legitimate messages to be rejected, but will not provide effective protection. However, message annotation can be far more stringent, non-disruptive, and offer effective and dependable protections.

1.2.  When Things Go Wrong

The introduction of DKIM occurs amidst reports declaring a rise in bot-nets [r‑MS‑Trends] (Microsoft Corp., “The Windows Malicious Software Removal Tool: Progress Made, Trends Observed,” June 2006.) [r‑UT‑Sneak] (USA TODAY, “Malicious-software spreaders get sneakier, more prevalent,” April 2006.), DNS and router poisoning [r‑CW‑Steal] (Computerworld, “Spammers Steal IP Addresses,” January 2006.) [r‑CU‑Peril] (Cornell University, “Perils of Transitive Trust in the Domain Name System,” October 2005.), and DDoS attacks [r‑VS‑Reflect] (Verisign, “Recent DNS Reflector Attacks From the Victim and the Reflector POV,” June 2006.). These problems are increasing the need for both defensive strategies, and an ability to react quickly and effectively when new exploits are discovered. For the Internet to remain viable, security must improve beyond its existing state. Although most security issues are related to the operating system, the Internet infrastructure must also become more robust.

Highly targeted attacks employing substantial resources might become a moderately plausible threat to the protections offered by DKIM. There are millions of compromised systems throughout the Internet, where many are covertly controlled by specialized peer-to-peer communication schemes. Although service providers may attempt to restrict traffic between peer-to-peer applications, a reaction to the imposed limitations has been to change how these applications communicate by encrypting the data and selecting random network ports. These changes thus evade a service provider's normal means of control. Peer-to-peer communication represents both a large and a growing portion of overall traffic, where efforts aimed at locating malicious nodes and resolving the origins of a command and control channel becomes increasingly difficult.

DKIM currently allows a signature and a common DKIM key to validate email-address from an entire domain as well as from all of the subdomains. The transparent nature of DKIM makes it attractive for transactional messages, because the appearance of the message remains clean and unaltered, and additional recipient-based annotations can be used to differentiate trusted signing domains. While unsigned emails will always be viewed with skepticism, DKIM provides a basis for trusting the message's origin. This makes DKIM a prime target for those wishing to defraud. When a DKIM deployment becomes compromised, the trust DKIM established will be the commodity most utilized by those attempting to defraud the recipient.

An optional 'i=' parameter within DKIM is intended to "implicitly" validate email-addresses contained within the message. This email-address validation assertion can broadly apply to any address within the signing domain and any subdomain, irrespective of subdomain delegations. This sweeping and domain-wide application of DKIM comes at a time when DNS and routing infrastructure is increasingly faltering.

For the sake of convenience, the DKIM key can validate an email-address when located within any parent subdomain. This convenience causes a multiplicative reduction in the validation integrity by the number of the domains that are considered authoritative. The resulting increase in the number of failure points for email-address validation also imposes far greater efforts when resolving and repairing such failures. Email validation failure resolution and repair may also require additional contractual agreements be established regarding DKIM related obligations and duties of the administrators of higher level domains. These agreements need to be established and be extended well beyond normal domain delegation requirements.

The current DKIM base draft appears to represent an attitude that places an emphasis upon the ease of publishing DKIM DNS resource records over that of security. These concessions allow the effects of a compromised key to cascade down into all subdomains. To selectively curb the extent of damage, there is now an optional method to prevent a key from validating email-address subdomains. Without this restrictive option, a vast number of email-address subdomains could be fabricated and validated by the 'i=' parameter within the DKIM signature header field.

Even when confronting issues that are beyond the control of the administrator, such as a compromised key within a higher level domain, a reaction strategy should assume the success in compromising DKIM by some method of attack occurs only intermittently. Otherwise, an abrupt and disruptive response to major failures makes any orderly transitional mechanism appear to be of little benefit. Broad adoption of any change may take years, which necessitates careful consideration of the transition process where a deprecated status may prevail for years.

2.  Definitions

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

Definitions:

Deprecated - The element will be made obsolete in the future.

Obsolete - The element is currently invalid.

3.  Deprecated Versions

Much like when dealing with a car that has a faltering engine, repair is likely to be sought in conjunction with continued use. An intermittent exploit may cause the available DKIM services or algorithms to be considered deprecated by an entity affected when their messages are being spoofed. After upgrading to a different version of DKIM supporting a more robust alternative, the affected domain still needs to offer the deprecated signature by including two signatures, the new and deprecated, with the message. The use of two signatures is essential when a significant number of verifiers have yet to upgrade, and when not offering a compatible signature has unacceptable consequences.

Abruptly dropping a supported signature version in favor of a more robust, albeit poorly supported alternative, will cause recipients to see these messages as being unsigned. This strategy will likely cause recipients to once again not know what to trust and, as a result, deal again with the flood of spoofed messages. An abrupt change, even with out-of-band policy assertions, still permits simple exploits where a fake signature only needs to claim to utilize the now required newer signature version. When only intermittent exploits would have otherwise occurred, an abrupt transition or switch-over from a faltering DKIM version would prove much more detrimental and disruptive.

Providing two signatures is a safer strategy during a transition seeking to thwart intermittent exploits. Once the verifier has also been upgraded, a means to indicate this transition within the existing mechanism is required. Without this signaling mechanism, a downgrade attack remains possible. This signaling mechanism is lacking in the present base draft. The attacker only needs to remove the more robust signature as a way to continue their exploit.

As the targeted entity would be the first to upgrade, knowledge of what represents a deprecated DKIM version is initially understood by only those first few domains. Even after a verifier has been upgraded, during the two-signature transitional phase, the verifier is still unable to discern which signing MTA has also been upgraded. Without the signing domain being able to communicate what is considered to be deprecated within prior signature constructs, intermittent exploits can continue.

Without a signaling method, this exploit remains viable over the entire transitional phase, which may take years. Intermittent exploits will remain a problem even when both the signing and verifying domains have long since been upgraded. Attempting to create an out-of-band method for exchanging this information offers no additional benefits, but does create unnecessary overhead. Not having a signaling method, preferably within the existing signature constructs, will result in diminished benefits for early upgrading, and may slow the adoption of the upgrade.

There must be a parameter within the existing signature header and the key that conveys whether the signing domain has upgraded. Logically, since any element of the DKIM signature might be affected, the reported signature version should offer a key parameter declaring that the signing domain now considers this version of the DKIM signature to be deprecated. In essence, this signature is offered only for compatibility during a two-signature transitional phase.

A message containing only a deprecated version from the signing domain should be ignored. When a non-deprecated version is found to be not supported, the verifier should confirm the signing domain actually offers this version. To enable this confirmation, the signing domain declares the specifics of this transition by listing the non-deprecated VAQ parameters (Version, Algorithm and Query mode) within the key used by the deprecated signature. The VAQ valued contained within the 'c=' parameters are the non-deprecated Version, Algorithms, and Query methods that must accompany this signature within a concurrent signature added to the message. A key with the 'c=' parameter marks the associated DKIM Signature as deprecated.

The current base draft expects verifiers, irrespective as to whether the signing domain was upgraded, to abruptly ignore deprecated (rather than correctly stated as an obsolete) signatures. This method is highly disruptive when only a small number of domains have adopted the alternative. The verifier ignoring deprecated signatures early within a transitional phase may expose their recipients to a flood of fraud, instead of a few intermittent instances of exploits.

This outcome, caused by not having a ready means to communicate the version status of the signing domain, implies an intermittent exploit will likely continue over the entire transitional phase, perhaps measured in years. In contrast, when there is a mechanism for the signing domain to communicate the status of a signature's version, its adoption by the affected domains and by a number of major ESPs can restore protection for most recipients within weeks. This can be done without any out-of-band communication, which carries associated risks and overhead. This rapid recovery of DKIM protections should also help promote the upgrade process. The following is a recommendation that makes a minor change to the DKIM version value and offers a method to signal a two-signature transitional phase.

  ,----
  | 4. Semantics of Multiple Signatures
  | ...
  | When evaluating a message with multiple signatures,
  | a receiver should evaluate signatures independently
  | and on their own merits.  For example, a receiver
  | that by policy chooses not to accept signatures
  | with deprecated crypto algorithms should consider
  | such signatures invalid.  As with messages with a
  | single signature, receivers are at liberty to use
  | the presence of valid signatures as an input to
  | local policy; likewise, the interpretation of
  | multiple valid signatures in combination is a local
  | policy decision of the receiver.
  '____

  Change to:
  : When evaluating a message with multiple signatures,
  : a receiver should evaluate signatures by different
  : signing domains independently.  A receiver,
  : that by policy considers a crypto algorithm or
  : service to be obsolete, should ignore the signature
  : and consider it invalid.  Multiple signatures by the
  : same domain must include at least one signature
  : version that has not been marked as deprecated.
  : When a non-deprecated version of a signature from the
  : same domain is supported, this signature should be
  : used in preference to a signature marked as
  : deprecated.  When an unsupported signature is found
  : from a domain where the only other supported signature
  : is marked as deprecated, the version details listed
  : within the 'c=' parameter of the deprecated
  : signature must match the values found within the
  : unsupported signature, otherwise the deprecated
  : signature should be ignored. As with messages with a
  : single signature, receivers are at liberty to use the
  : presence of valid signatures as an input to local
  : policy; likewise, the interpretation of multiple valid
  : signatures in combination is a local policy decision
  : of the receiver.

 Add:
  :3.5 The DKIM-Signature header field
  : ...
  : c=  When the signing domain considers the associated
  :     signature "deprecated", this parameter contains the VAQ
  :     values (Version, Algorithm, and Query method) of the
  :     required concurrent non-deprecated signature
  :     (quoted-printable; OPTIONAL, default is empty).
  :
  :     ABNF:
  :
  :  con-v        = <non-deprecated sig 'v=' value>
  :  con-a        = <non-deprecated sig 'a=' value>
  :  con-q        = <non-deprecated sig 'q=' value>
  :  con-list     = con-v [1*("|" con-a) ["|" con-q ]]
  :  key-c-tag    = %x63 [FWS] "=" [FWS] [con-list]
  :

4.  Questionable Provisions for 2048bit Keys

Without reliance upon a TCP fall-back or an [RFC2671] (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.) EDNS0 extension which can normally take message sizes from 512 to 1280 bytes, the DNS Message is constrained to 512 bytes. Many within the working group expect the need for 2048 bit keys will happen well after DNSSEC has ensured full support of EDNS0 will be available. What happens when the 2048 bit key is needed sooner? Keep in mind that DKIM is also employed at the MUA.

Within the DNS message allotment, 12 bytes contain the DNS message header, 5 bytes contain the query, plus the number of bytes to accommodate the name, plus one byte per label overhead. Also add the 9 bytes that contain the response, plus 2 bytes per label (assuming name compression) followed by the RR data. Not including the name requirements, there are 486 bytes available within this DNS message allotment. A TXT RR holding more than 255 characters also contains an additional two bytes for defining the character-string length, which leaves 484 bytes for the key related data and the name information. The name information would require the sum of the label sizes plus 3 additional bytes per label.

The present definitions for the DKIM TXT key information represent a text structure as follows:

    ABNF:

        CRLF = %d13 %d10
         WSP = %d32 | %d9
         FWS = ([*WSP CRLF] 1*WSP) / 1*WSP *(CRLF 1*WSP)

    tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]

    tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]

The key includes provisions for accommodating folding whitespace, but is never held within an email header where this could be required. The key storage is defined as "p=<base64>;" which defines 6 bits per character. Storing a 2048 bit key in this manner requires 345 bytes. Other key elements are the version "v=DKIM1;" for 8 bytes, a localpart requirement "g=<localpart>;" for 0-67 bytes, the acceptable hash list "h=sha1:sha256:?;" for 0-14+ bytes, the key algorithm "k=<rsa>;" 0-6 bytes, and the test flag 't=<y;>' for 0-4 bytes. There is also the ";n=<note>;" and the "s=<services>;" elements which may require from 0 bytes to an unknown size.

The following size estimates will ignore elements with an unknown size and any possible future elements. After excluding these unknowns from consideration, the key-related data may contain anywhere from 352 to 443 bytes. This leaves anywhere from 132 to 41 bytes for the name information. The mandatory "_domainkey" label consumes 13 bytes, leaving from 119 to 28 bytes remaining for the rest of the name information. From this space, one or more selector labels, and the labels for the signing domain must be accommodated which consumes three bytes per label added to the size of the labels. Assuming DKIM is used by a 4 label signing domain with a single label for the key selector, that leaves somewhere from 104 to 13 bytes for the 5 labels and the 'n=' and 's=' elements. When the elements defined for the key are being used, which may happen with declaring newer crypto algorithms, these 5 labels must then average less than 3 character in size which indicates a significant likelihood of exceeding the message size constraints. There is a solution that solves this problem while also eliminating possible DoS attack techniques.

An alternative approach uses a resource record similar to the [RFC2538] (Eastlake, D. and O. Gudmundsson, “Storing Certificates in the Domain Name System (DNS),” March 1999.) Cert RR. The 5 byte CERT header specifies the type of key, the key tag, and the crypto algorithms in less space than that used for the DKIM TXT RR version alone. The CERT header approach clearly assures which algorithm set has been defined without resorting to a mix of default or mandated parameters.

The text based mnemonic list approach may cause a potential problem with future upgrades by introducing problematic size constraints that may prevent upgrading. Using a Tag-Length-Value (TLV) binary structure to store a 2048 bit key requires 258 bytes, which saves 87 bytes from that used by the TXT RR approach. The savings from a binary key storage, together with binary algorithm definitions, ensure that future algorithm upgrades, added features, or even the utilization of some of the current features are not in jeopardy of requiring dependence upon EDNS0. A binary key structure ensures there is truly a 2048 bit key option readily and immediately available without introducing unexpected overflow issues while EDNS0 remains unavailable.

Below is an example of a TLV definition for a binary DKIM RR:

     0             7 8             15
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Version     |   Algorithm   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0       4 5                   15
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Tag    |       Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \             Value             \
    /                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Tag
    ---
    0 = reserved
    1 = key data
    2 = granularity
    3 = services
    4 = notes
    5 = test (test mode defined with 0 Length)
    6 - 31 reserved

Reticence in implementing a new DNS resource record appears to be based upon an understanding that a major software vendor is unable to handle these new types. Another factor is that publishing binary information for a new resource record requires the DNS server be updated first. The reliance upon text and using mnemonics with tags and delimiters is a highly inefficient use of DNS resources, although this is typical for email. There are times when counting bytes really matters from a security standpoint, and DNS is a prime example.

Running out of space, a prior email authorization scheme developed a method to chain TXT resource records. This technique can result in a sizable DDoS exploit, see [I‑D.otis‑spf‑dos‑exploit] (Otis, D., “SPF DoS Exploitation,” June 2006.). Unlike most DNS related exploits, this exploit does not depend upon an answer being larger than the query, while still achieving massive network amplifications. A different exploit strategy could also use this TXT based script to lookup a sequence of eleven TXT resource records, which includes TXT records used by DKIM.

Before dismissing concerns about the size of a DNS resource record, keep in mind that this dangerous sequence of TXT lookups occurs for each name being qualified. One of those names may also include one of a number of DKIM signing domains. Once the DKIM working group develops a binary DNS resource record, this will provide a major benefit in respect to several security related issues. The DKIM working group should attempt to demonstrate there is an alternative to the bad practice of commandeering TXT records and then defining everything with text, as though DNS/UDP was HTTP/TCP.

5.  Email-Address Validation

Perhaps the weakest aspect of DKIM is found in the method used to validate the email-address. The base draft provides no explicit means for the signing domain to indicate whether there was some type of verification made related to the email-address. The base draft assumes that because the message was signed, the email-address has been verified in some fashion. While some signing domains may impose this type of restriction, it is also likely that a number of signing domains will not. Without an explicit indication being provided, an assumption is made about whether the email-address has been verified by the signing domain. Any annotations based upon such an assumption places the recipient at risk, and should be avoided for security reasons. Explicit indications of the verification of the email-address should be expressed by including the localpart of the email-address in the DKIM signature header field 'i=' parameter.

The following is a recommendation to ensure the email-address validation is explicit.

,---
|5.1  Determine if the Email Should be Signed and by Whom
|...
|A signer MUST NOT sign an email if it is unwilling to be held
|responsible for the message; in particular, the signer SHOULD ensure
|that the submitter has a bona fide relationship with the signer and
|that the submitter has the right to use the address being claimed.
'___

Change to:
:A signer MUST NOT sign an email if it is unwilling to be held
:responsible for the message; in particular, the signer SHOULD ensure
:that the submitter has a bona fide relationship with the signer and
:that the submitter has the right to use the address when a specific
:address is noted in the i= parameter as denoted by the inclusion of
:the email-address local-part.

6.  Use of Fabricated Subdomains within DKIM Identity Validations

TLD managers are trustees for the delegated domains. However, DKIM's use of fabricated subdomains within the signature's 'i=' parameter for email-address validation introduces a security concern unrelated to domain delegation. Registry Operator Functional Specification Agreements normally preclude registering "_domainkey" due to the underscore character. This limitation is expected to also preclude TLD managers from publishing the "_domainkey" label as a subdomain. There are also unsanctioned TLD managers and SLDs managers operating under a variety of agreements. Some are known to include domains exceeding normally prescribed characters which may allow DKIM keys to be published within these higher level domains.

Utilizing fabricated subdomains created within DKIM-Signature header field 'i=' parameter allows a DKIM key referenced from any higher level domain to validate an email-address containing these subdomains. This provision might be exploited to usurp the validation of an email-addresses of a lower domain. As a result, DKIM keys published at a higher level may expose subdomains to harm from a possible security breach at a higher level and to conflicts with regard to what is a valid email-address. For example, the key's 'g=' localpart template provision permitting MUA signing may not also restrict the subdomains included within the DKIM-Signature 'i=' parameter.

Unless otherwise already precluded by existing agreements, a DKIM operator will need to establish separate agreements governing the high-level domain's covenants as related to the specific use of the "_domainkey" subdomain. These new functional requirements should include limitations on key retention periods, key sizes, the handling of the private key, and whether address validation assertions are permitted within lower level domains.

The Threat document failed to distinguish between obligations related to the specific delegation of a zone and to the use of a subdomain within different delegated zones. The considerations within this section could be added to the Security Considerations section of the base document. The considerations within this section are based upon the premise that contractual agreements resolve the problems. It remains doubtful that such agreements can be established in a timely fashion and ultimately prove effective.

A safer and simpler alternative, requiring no changes to existing agreements, is to make a minor change to the base draft that prohibits the use of the virtual subdomains. With this minor alteration, when there is a desire to have an email-address validated, a DKIM key must be referenced from that domain. This is accomplished by the following changes:

,---
|3.5  The DKIM-Signature header field
|...
|d=  The domain of the signing entity (plain-text; REQUIRED).  This
|    is the domain that will be queried for the public key.  This
|    domain MUST be the same as or a parent domain of the "i=" tag
|    (the signing identity, as described below).  When presented with
|    a signature that does not meet this requirement, verifiers MUST
|    consider the signature invalid.
|...
|i=  Identity of the user or agent (e.g., a mailing list manager) on
|    behalf of which this message is signed (quoted-printable;
|    OPTIONAL, default is an empty localpart followed by an "@"
|    followed by the domain from the "d=" tag).  The syntax is a
|    standard email address where the localpart MAY be omitted.  The
|    domain part of the address MUST be the same as or a subdomain of
|    the value of the "d=" tag.
'___

Change to:
:d=  The domain of the signing entity (plain-text; REQUIRED).  This
:    is the domain that will be queried for the public key.
:...
:i=  Identity of the user or agent (e.g., a mailing list manager) on
:    behalf of which this message is signed (quoted-printable;
:    OPTIONAL, default is an empty localpart followed by an "@"
:    followed by the domain from the "d=" tag).  The syntax is a
:    standard email address where the localpart MAY be omitted.  The
:    domain part of the address MUST be the same as the value of the
:    "d=" tag.

,---
|6.1  Extract the Signature from the Message
| ...
|
|Verifiers MUST confirm that the domain specified in the "d=" tag is
|the same as or a superdomain of the domain part of the "i=" tag.  If
|not, the DKIM-Signature header field MUST be ignored and the
|verifier should return with DKIM_STAT_SYNTAX.
'___

Change to:
:Verifiers MUST confirm that if a domain is specified in the "i="
:tag, that this is the same domain in "d=" tag.  If not, the
:DKIM-Signature header field MUST be ignored and the verifier
:should return with DKIM_STAT_SYNTAX.

7.  Deletion of Invalid Signatures

The present draft does not provide safe guidance regarding invalid signatures. An invalid signature offers no protective value. An invalid signature however does pose a risk related to DoS exploits when a verifier must search for a valid signature and many are available. Perhaps due to pathological cases where a signature gets reordered, heroic searches for valid signatures might become practiced. The current base draft includes a statement which ensures the likelihood of invalid signatures accumulating within messages, and creating this risk.

,---
|4.  Semantics of Multiple Signatures
| ...
|
|Signers SHOULD NOT remove any DKIM-Signature header fields from
|messages they are signing, even if they know that the signatures
|cannot be verified.
'___

Change to:
:Signers SHOULD NOT include any DKIM-Signature header fields from
:messages they are signing, unless the signature was previously
:verified by the signer.

8.  Email-Address Recognition Option

The DKIM Threat [I‑D.ietf‑dkim‑threats] (Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM),” May 2006.) document indicates there is both high impact and high likelihood of international domain abuse. This problem will affect both right and left sides of the email-address. Although the 'i=' parameter may indicate the email-address has been validated, it would be incorrect to assume that the recipient is able to visually differentiate email-addresses. This means the email-address can not safely offer a means to partition messages from sources of various levels of trust. The partitioning can be accomplished by the signing domain signaling assurances that a particular message is from a well vetted source.

One half of the solution for overcoming the recognition problem would be to mark these messages with an 'r=' value as defined in [I‑D.otis‑dkim‑reliance‑level] (Otis, D., “DKIM Signing Domain Reliance Level,” May 2006.). This document describes three different reliance levels that can be used to annotate the messages. A reliance value of 1 indicates an added assurance has been offered. This might be messages from a system administrator or a department manager, for example. This assurance, when missing or at a value of 0, can also act as a type of warning. Perhaps the signing domain also signs guest's messages, but for whom the source is not well vetted at all. The signing domain can increase this warning, by offering a reliance level of -1. The reliance level can overcome the issue of recognizing the localpart of the email-address, but there still remains the problem of recognizing the signing domain.

The other half of solution for domain recognition would be a list of trusted transactional domains. This list might be established by a community effort, much like the effort at http://adblock.mozdev.org, or a list offered by an organization such as the Anti-Phishing Working Group. By limiting annotations that offer assurances to messages where the signing domain is found on a trusted list, and also where the signing domain has offered a reliance level of 1, there should be little need for the recipient to recognize the email-address in order to know when the message is trustworthy. Instead, the recipient can rely upon just the message annotations.

Of course, no trusted list would be complete, and as a result, the recipient would need to add signing domains to the list from time to time. When subscribing for some type of service from a website, a pass-phrase could be established to assure the recipient the correct signing domain is being added to the list. This list could be a component of the MUA Address Book. In addition to the Address Book being updated by a centralized service, the recipient could append to this Address Book as needed. There could even be extensions added within the MUA to MDA interfaces to support this effort.

Once DKIM signed messages are widely deployed and are anticipated with any critical transaction, there would be little value afforded by an out-of-band policy scheme. Just the additional transactions expended to obtain these policies could further add to DoS concerns. Rather than attempting to erect obstacles that limit the free use of an email-address, consider the opportunistic validations that can be obtained by a free association of email-addresses with that of signing domains. Allowing individuals the freedom to use their favorite or desired email-address improves security when opportunistic methods are used. Opportunistic security can be significantly enhanced by adding an opaque identifier as described in Section 9 (Opaque-Identifier Option).

9.  Opaque-Identifier Option

As described below, the Opaque-Identifier (O-ID) is an option that supports two different mechanisms and two different modes. One mechanism isolates the source of a message to that of a specific account. The other mechanism provides a means to revoke messages being abusively replayed.

An O-ID added to the signature header MUST also be a valid domain name label. The term 'opaque' means only the domain creating the identifier understands the associations. There are two modes for creating the O-ID. One mode would make the O-ID persistent with the account used to access the signing-domain, which means the value identifies the unnamed account. The other mode could be just a sequential assignment for those cases where an account is not involved. A prefix added to a sequential O-ID prevents collisions with identifiers used for accounts.

If an identifier were added to an unsigned message, this would invite forgery and would therefore offer little value. On the other hand, a standardized O-ID, included within the validated content of a signed message, would offer significant value. A persistent O-ID would be most useful and could be derived from the access server that authenticates the account being used. This would enable the use of opportunistic identification techniques that recognize or annotate messages based upon the recognition of the signing domain in conjunction with that of the O-ID.

A sequential O-ID may be appropriate when distributing bulk mailings. In order to identify abusers that may attempt to stage replay attacks, having a unique identifier for each recipient could prove helpful. The replay attacks could be done using the unchanged content of the message, but sent to recipients that would consider the information to be unsolicited. The reason for such a replay attack may be to damage the reputation of the signing-domain. The sequential O-ID would identify the miscreant and provide a low impact method for revoking the message.

The persistent O-ID would greatly aid the correlation of abuse and the location of compromised systems. This identifier could be effective against systems compromised by malware, stolen passwords, and cracked wireless access points, and by many other nefarious methods. Abuse reports that catalog signed messages and that are correlated with a persistent O-ID would provide incontrovertible evidence where the source of a problem exists. The publishing of the revocation record for the O-ID would also provide feedback that actions were taken to rectify a policy breach.

In odd cases where an EHLO does not correlate with the signing domain, a single lookup of a revocation record for the O-ID returning no record is an indication that this particular O-ID is still authorized by the signing domain. This mechanism, although intended for a small percentage of the messages, is valuable when the message is forwarded, such as at the typical alma mater, or when a mailing list opts to forward signed messages unaltered. This mechanism allows messages passing through such servers to be revoked when abuse is reported. To allow time for a revocation process, when the source of the message has not been white-listed, acceptance might also be delayed.

If there is a problem, the signature offers the name of the most capable domain able to remedy abuse. The O-ID can be used to cope with the situation when the signing domain is not associated with the EHLO. This coping feature should ensure people will remain free to use their forwarding email accounts given to them by their school or society. The O-ID can also provide mailing lists a better means to identify their subscribers without also requiring that there be a relationship between the email-address and the signing domain. Complaints referencing this essential identifier will also assist those curtailing future episodes of bad behavior, i.e. the providers of the abusive account.

Within the signature header, a 'u=<Opaque-Identifier>' parameter would indicate the use of an O-ID. The operation of this revocation record mechanism takes the form of a single A record lookup, where the return of a record indicates the O-ID has been revoked. The O-ID would be composed of 1 to 63 characters and select a record in this fashion:

  <Opaque-Identifier> ::= <mode> [ [ <ldh-str> ] <let-dig> ]
  <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
  <let-dig-hyp> ::= <let-dig> | "-"
  <let-dig> ::= <letter> | <digit>
  <letter> ::= %x41-5A / %x61-7A
  <mode> ::= "P" |  "S"
    ; Persistent and Sequential O-ID assignment
  <digit> ::= %x30-39
  <Opaque-Identifier>._dkim-or.<signing-domain> IN A 127.0.0.2

When the first letter in the O-ID is 'P,' it represents an identifier where the portion of the identifier to the right of the leftmost '-' character is persistent with the account used to obtain access. When the first letter is 'S,' then no portion of the identifier can be used to isolate which account was used to obtain access.

When the signing-domain has not revoked authorization for the O-ID, no record would be returned and the remote DNS cache would retain the absence of this record for a brief period of time, see [RFC2308] (Andrews, M., “Negative Caching of DNS Queries (DNS NCACHE),” March 1998.). For the majority of cases, when messages are obtained directly from the signing-domain, correlation with the EHLO would allow the O-ID revocation check to be skipped. The correlation of this signing domain with that of the EHLO could also be achieved with forward references to a PTR resource record as defined in [I‑D.otis‑smtp‑name‑path] (Otis, D., “SMTP Name Path Registration,” April 2006.).

For the small percentage of messages where a check is needed, the O-ID revocation check would be performing nearly an identical lookup that is now ubiquitously done to investigate the status of the SMTP client's IP address against a DNS black-hole list. Those addresses or identifiers that warrant refusal are granted a long lived address record to ensure their immediate refusal and to limit DNS traffic resulting from these abusive sources. Not offering a record allows for the prompt cessation of an O-ID's authorization when the situation regarding a particular identifier changes. The Time-To-Live for negative DNS caching may be determined by the recipient, or represent the lesser of the SOA TTL or the SOA MINIMUM field, depending upon the recipient's implementation.

10.  IANA Considerations

There are no IANA considerations.

11.  Security Considerations

This document describes security improvements for the [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” February 2007.) document.

12.  References

12.1. Normative References

12.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2009).

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.