DKIM D. Otis
Internet-Draft Trend Micro, NSSG
Expires: December 20, 2006 June 18, 2006
DKIM Security Concerns
draft-otis-dkim-security-concerns-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Otis Expires December 20, 2006 [Page 1]
Internet-Draft DKIM Sec June 2006
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deprecated Versions . . . . . . . . . . . . . . . . . . . . . 5
4. Questionable Provisions for 2048bit Keys . . . . . . . . . . . 10
5. Email-Address Validation . . . . . . . . . . . . . . . . . . . 13
6. Email-Address Recognition . . . . . . . . . . . . . . . . . . 14
7. Opaque-Identifier . . . . . . . . . . . . . . . . . . . . . . 15
8. Use of Virtual subdomains within DKIM Identity Validations . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Otis Expires December 20, 2006 [Page 2]
Internet-Draft DKIM Sec June 2006
1. Introduction
The current DKIM base document [I-D.ietf-dkim-base], 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 have been included only to provide a more
complete picture of possible follow-on efforts.
The foot-hold that email provides for the 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.
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. DKIM will allow recipients to know what can be
trusted. Knowing what to trust goes a long way toward removing that
criminal foot-hold. Since control must be at the signing domain, so
must be the trust.
The introduction of DKIM occurs amidst reports declaring a rise in
bot-nets [r-MS-Trends] [r-UT-Sneak], DNS and router poisoning [r-CW-
Steal] [r-CU-Peril], and DDoS attacks [r-VS-Reflect]. These problems
are increasing the need for both defensive strategies, and an ability
to react quickly 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 file-sharing 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
Otis Expires December 20, 2006 [Page 3]
Internet-Draft DKIM Sec June 2006
differentiate trusted signing domains. While unsigned emails will
always be viewed with skepticism, DKIM is attempting to provide 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 parameter within DKIM also validates specific email-
addresses contained within the message. This email-address
validation assertion can 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 the DNS and routing infrastructure is increasingly faltering.
For the sake of a 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 will also impose 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 a 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. Although
private DKIM keys located at an MUA within a employee's notebook may
have the localpart restricted, there is no method to restrict the
email-address subdomains this key may validate. Any key therefore
allows a vast number of virtual email-addresses to be validated.
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.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Otis Expires December 20, 2006 [Page 4]
Internet-Draft DKIM Sec June 2006
document are to be interpreted as described in [RFC2119].
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.
Otis Expires December 20, 2006 [Page 5]
Internet-Draft DKIM Sec June 2006
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 value 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 within the deprecated key. The VAQ
parameters are the non-deprecated Version, Algorithms, and Query
methods placed in the 'n=' parameter. A key with a deprecated
version MUST contain the VAQ values in the 'n=' parameter or should
be ignored.
The current base draft expects verifiers, irrespective as to whether
the signing domain was upgraded, to abruptly ignore a deprecated
(rather than correctly stated as an obsolete) signature. 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
Otis Expires December 20, 2006 [Page 6]
Internet-Draft DKIM Sec June 2006
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 signature is
: marked as deprecated, the version details listed
: within the 'n=' parameter of the deprecated
: key 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.
Otis Expires December 20, 2006 [Page 7]
Internet-Draft DKIM Sec June 2006
,---
|3.5 The DKIM-Signature header field
| ...
| v=
| Version (MUST be included). This tag defines
| the version of this specification that applies
| to the signature record. It MUST have the
| value 0.2.
|
| ABNF:
|
| sig-v-tag = %x76 [FWS] "=" [FWS] "0.2"
'___
Change to:
: v=
: Version (MUST be included). This tag defines
: the version of this specification that applies
: to the signature record. It MUST have the
: numeric value 0.2. The signing domain may
: mark the signature as deprecated by appending
: a "d" character to the version value.
:
: ABNF:
:
: dkim-sv = "0.2"
: sig-v-tag = %x76 [FWS] "=" [FWS] dkim-sv ["d"]
,---
| 3.6.1 Textual Representation
|...
| v=
| Version of the DKIM key record (plain-text;
| RECOMMENDED, default is "DKIM1"). If specified,
| this tag MUST be set to "DKIM1" (without the quotes).
| This tag MUST be the first tag in the response.
| Responses beginning with a "v=" tag with any other
| value MUST be discarded.
|
| ABNF:
|
| key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1"
|...
| n= Notes that might be of interest to a human (quoted-printable;
| OPTIONAL, default is empty). No interpretation is made by any
| program. This tag should be used sparingly in any key server
| mechanism that has space limitations (notably DNS).
|
Otis Expires December 20, 2006 [Page 8]
Internet-Draft DKIM Sec June 2006
| ABNF:
|
| key-n-tag = %x6e [FWS] "=" [FWS] qp-section
'___
Change to:
: v=
: Version of the DKIM key record (plain-text;
: RECOMMENDED, default is "DKIM1"). If specified,
: this tag MUST be set to "DKIM1" (without the quotes).
: This tag MUST be the first tag in the response.
: Responses beginning with a "v=" tag with any other
: numeric value MUST be discarded. The signing domain
: may mark the key as deprecated by appending
: a "d" character to the version value. When the
: DKIM-Signature version is marked as deprecated,
: the DKIM-Key version MUST BE included and marked as
: deprecated.
:
: ABNF:
:
: dkim-kv = "1"
: key-v-tag = %x76 [FWS] "=" [FWS] "DKIM" dkim-kv ["d"]
:
: INFORMATIVE IMPLEMENTATION NOTE: The DKIM Signature and
: Key versions will both have the numeric value "1" in the
: final draft.
:...
: n= Notes that might be of interest to a human and, when
: version for the key is marked "deprecated", the
: VAQ values of the concurrent non-deprecated
: signature are prepended (quoted-printable; OPTIONAL,
: default is empty). Except for the version details, no
: interpretation is made by any program. This tag should
: be used sparingly in any key server mechanism that has
: space limitations (notably DNS).
:
: ABNF:
:
: new-v = <non-deprecated sig 'v=' value>
: new-a = <non-deprecated sig 'a=' value>
: new-q = <non-deprecated sig 'q=' value>
: new-list = "|" new-v "|" new-a "|" new-q "|"
: key-n-tag = %x6e [FWS] "=" [FWS] [new-list] qp-section
:
Otis Expires December 20, 2006 [Page 9]
Internet-Draft DKIM Sec June 2006
4. Questionable Provisions for 2048bit Keys
Without reliance upon a TCP fall-back or an [RFC2671] 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
Otis Expires December 20, 2006 [Page 10]
Internet-Draft DKIM Sec June 2006
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] 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:
Otis Expires December 20, 2006 [Page 11]
Internet-Draft DKIM Sec June 2006
0 7 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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]. 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
Otis Expires December 20, 2006 [Page 12]
Internet-Draft DKIM Sec June 2006
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
verification 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 greater number of
signing domains will not. Without an explicit indication, there
should not be any assumptions made about whether the email-address
has been verified by the signing domain.
Verification of the email-address could be expressed by including the
localpart of the email-address in the DKIM signature header field
'i=' parameter. This 'i=' parameter should not be allowed to include
any subdomains, as there are no provisions for constraining the use
of these virtual subdomains. Preventing the use of the subdomain
within the 'i=' parameter removes concerns related to how DKIM might
be used within higher levels of the DNS hierarchy.
Allowing virtual subdomains within the 'i=' parameter means that when
a key becomes compromised, even when the localpart is restricted,
there would be no means to block just the email-address. The
likelihood of this problem is high when signing occurs at the MUA.
To avoid collateral blocking, the key selector ('s=') and the signing
domain ('d=') would need to be used to block the abusive messages.
This added effort breaks many tools commonly available for
accomplishing the task of sorting and blocking messages based upon
the email-addresses. The problem is resolved by the recommended
changes in Section 8 Paragraph 4. The following is a recommendation
to ensure the email-address validation is explicit.
Otis Expires December 20, 2006 [Page 13]
Internet-Draft DKIM Sec June 2006
,---
|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.
6. Email-Address Recognition
The DKIM Threat [I-D.ietf-dkim-threats] 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]. 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
Otis Expires December 20, 2006 [Page 14]
Internet-Draft DKIM Sec June 2006
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 7.
7. Opaque-Identifier
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.
Otis Expires December 20, 2006 [Page 15]
Internet-Draft DKIM Sec June 2006
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
Otis Expires December 20, 2006 [Page 16]
Internet-Draft DKIM Sec June 2006
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].
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].
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-
Otis Expires December 20, 2006 [Page 17]
Internet-Draft DKIM Sec June 2006
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.
8. Use of Virtual subdomains within DKIM Identity Validations
TLD managers are trustees for the delegated domains. However, DKIM's
use of virtual subdomains 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
alternative 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 the unqualified subdomains of the 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 does not
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.
Otis Expires December 20, 2006 [Page 18]
Internet-Draft DKIM Sec June 2006
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:
Otis Expires December 20, 2006 [Page 19]
Internet-Draft DKIM Sec June 2006
,---
|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.
Otis Expires December 20, 2006 [Page 20]
Internet-Draft DKIM Sec June 2006
9. IANA Considerations
There are no IANA considerations.
10. Security Considerations
This document describes security improvements for the [I-D.ietf-dkim-
base] document.
11. References
11.1. Normative References
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail Signatures
(DKIM)", draft-ietf-dkim-base-02 (work in progress),
May 2006.
[I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006.
[I-D.otis-dkim-reliance-level]
Otis, D., "DKIM Signing Domain Reliance Level",
draft-otis-dkim-reliance-level-00 (work in progress),
May 2006.
[I-D.otis-smtp-name-path]
Otis, D., "SMTP Name Path Registration",
draft-otis-smtp-name-path-00 (work in progress),
April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
11.2. Informative References
[I-D.otis-spf-dos-exploit]
Otis, D., "SPF DoS Exploitation",
draft-otis-spf-dos-exploit-00 (work in progress),
April 2006.
Otis Expires December 20, 2006 [Page 21]
Internet-Draft DKIM Sec June 2006
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[r-CU-Peril]
Cornell University, "Perils of Transitive Trust in the
Domain Name System", October 2005,
<http://www.cs.cornell.edu/people/egs/beehive/paper.php>.
[r-CW-Steal]
Computerworld, "Spammers Steal IP Addresses",
January 2006, <http://www.computerworld.com/
securitytopics/security/story/0,10801,108175,00.html>.
[r-MS-Trends]
Microsoft Corp., "The Windows Malicious Software Removal
Tool: Progress Made, Trends Observed", June 2006, <http://
download.microsoft.com/download/3/d/e/
3de2470b-ab9a-4a7f-b760-ee2421df294a/
WindowsRemovalToolWP.doc>.
[r-UT-Sneak]
USA TODAY, "Malicious-software spreaders get sneakier,
more prevalent", April 2006, <http://www.usatoday.com/
tech/news/computersecurity/infotheft/
2006-04-23-bot-herders_x.htm>.
[r-VS-Reflect]
Verisign, "Recent DNS Reflector Attacks From the Victim
and the Reflector POV", June 2006,
<http://public.oarci.net/files/mlarson-dnsops.pdf>.
Otis Expires December 20, 2006 [Page 22]
Internet-Draft DKIM Sec June 2006
Author's Address
Douglas Otis
Trend Micro, NSSG
1737 North First Street, Suite 680
San Jose, CA 95112
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires December 20, 2006 [Page 23]
Internet-Draft DKIM Sec June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Otis Expires December 20, 2006 [Page 24]