TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2007.
Copyright © The Internet Society (2006).
DomainKeys Identified Mail [DKIM] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” July 2006.) [I‑D.ietf‑dkim‑base] provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism would allow an administrator to publish various statements about their DKIM signing practices. This draft defines the requirement for this mechanism.
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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Preface
2.
Definitions
3.
Introduction
4.
SSP Problem Scenarios
4.1.
Problem Scenario 1: All Mail Signed with DKIM
4.2.
Problem Scenario 2: Illegitimate Domain Name Use
4.3.
Problem Scenario 3: Domain Sends No Mail
5.
SSP Deployment Scenarios
5.1.
Deployment Scenario 1: Outsourced Signing
5.2.
Deployment Scenario 2: Determinism in Lookup Mechanism
5.3.
Deployment Scenario 3: Resent Original Mail
5.4.
Deployment Scenario 4: Incremental Deployment of Signing
5.5.
Deployment Scenario 5: Transport Scenarios
5.6.
Deployment Scenario 6: Human Legibility of Practices
5.7.
Deployment Scenario 7: Cryptographic Downgrade Attacks
5.8.
Deployment Scenario 8: Extensibility
5.9.
Deployment Scenario 9: Security
6.
Requirements
6.1.
Discovery Requirements
6.2.
Transport requirements
6.3.
Practice and Expectation Requirements
6.4.
Extensibility and Forward Compatibility Requirements
7.
Security Requirements
8.
IANA Considerations
9.
Security Considerations
10.
Acknowledgments
11.
References
11.1.
Normative References
11.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
TOC |
The purpose of this draft is get out into the open a range of issues related to the perceived need for a signing practices information service primarily focused on DKIM. This document is intended to document well-agreed upon problems and requirements, in addition to less well-agreed upon requirements in an attempt to capture the issue as well as generalize the requirement as much as possible. These latter requirements will be noted as "[PROVISIONAL]" to indicate that there is not yet solid consensus, or that the problem is not well understood. A winnowing process is envisioned where the more difficult and/or speculative problems/requirement will be eliminated unless concrete problems with proven constituencies can be demonstrated, along with reasonable plausibility that they do not contradict more well agreed upon requirements.
TOC |
TOC |
The DomainKeys Identified Mail working group is chartered to create a base signing mechanism for email. This work is contained in [I‑D.ietf‑dkim‑base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” July 2006.). In addition there are two other documents [I‑D.ietf‑dkim‑overview] (Hansen, T., “DomainKeys Identified Mail (DKIM) Service Overview,” June 2006.) and [I‑D.ietf‑dkim‑threats] (Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM),” May 2006.) which give an overview and a threat analysis of the chartered work. This draft reflects the requirements for the last part of the chartered work to define a protocol to publish DKIM signing practices.
While the base signing document defines a mechanism for signing and verifying DKIM signatures, there has been a great deal of interest in a signing practices protocol. The most pressing case seems to be the bid down attack inherent with almost all systems that allow optional authentication: how does a receiver know whether or not it should expect a message to contain authentication information? For email this is an especially difficult problem since there is generally no a priori knowledge of a sending domain's practices. If a protocol could be developed for a domain to publish its DKIM signing practices, a message verifier could take that into account when it receives a unsigned piece of email.
This draft is organized into two main sections: a Problem and Deployment Scenario section which describes the problems that The Protocol is intended to address as well as the deployment issues surrounding the base problems. The second section is the Requirements that arise because of those scenarios.
TOC |
The email world is a diverse place with many deployment scenarios. This
section tries to outline some usage scenarios that it is expected
that DKIM signing/verifying will take place in, and how a new protocol
might be helpful to clarify the relevance of DKIM signed mail.
TOC |
After auditing their outgoing mail and deploying DKIM signing for all of their legitimate outgoing mail, a domain could be said to be DKIM signing complete. That is, the domain has to the best of its ability insured that all mail legitimately purporting to have come from that domain contains a valid DKIM signature.
A receiver in the general case doesn't know what the practices are for a given domain, or what their expectations are for unsigned mail. Thus the receiver is at a disadvantage in that it does not know if it should expect mail to be signed from a given domain or not. This knowledge gap leads to a trivially exploitable bid-down attack where the attacker merely sends unsigned mail; since the receiver doesn't know the practices of the signing domain, it cannot treat the message any more harshly for lack of a valid signature.
An information service which allowed a receiver to query for the practices and expectations of the sending domain when no valid signature is found could be useful in closing this gap. A receiver could use this information to treat such questionable mail with varying degrees of prejudice.
Note that for the foreseeable future, DKIM signature breakage for unrestricted use patterns (eg where users are members of mailing lists, etc) will likely suffer occasional non-malicious signature failure in transit. While probably not a large percentage of total traffic, the kind (quality) of breakage may be a significant concern for those usage patterns. This scenario defines where the sender cannot set any expectation as to whether an individual message will arrive intact.
Even without that expectation, a receiver may be able to take advantage of the knowledge that the domain's practice is to sign all mail and bias filters against unsigned or damaged in transit mail. This information should not be expected to be used in a binary yes/no fashion, but instead as a data point among others in a filtering system.
TOC |
There seems to be a class of mail -- mostly transactional mail from high value domains -- that are the target of phishing attacks. In particular, many phishing scams forge the [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.).From address in addition to spoofing much of the content to trick unsuspecting users into revealing sensitive information. Domain holders sending this kind of mail would like the ability to give an enhanced guarantee that mail sent in their name should always arrive with the provable consent of the domain holder.
From a receiver's standpoint, knowing that a domain not only signs all of its mail, but also expects that legitimate mail from the domain will be received with a valid signature is quite interesting. This assertion from the signing domain is quite a bit stronger than the assertion in Problem Scenario 1; even though a signer can never know the true path mail will take before delivery, the implication is that if the message is lacking a valid signature the message is either malicious or is the responsibility of the signing domain to avoid whatever broke the signature.
[Informative Note: in terms of a receiving filter, one may choose to treat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is very wrong]
TOC |
A domain may not intend to send mail at all. In such a case, it could be advantageous for a receiver to know the domain's intent and would be likely to treat such mail very suspiciously. It has been noted that a solution to Problem Scenario 2 could potentially be used to emulate this practice. In reality, they are close but not precisely the same semantics. That is, a piece of email purporting to come from a domain which claims to send none is illegitimate on its face, whereas there may be some lingering doubt with Problem Scenario 2 given the possibility in deployments between whether one should publish scenario 1 and 2, etc.
TOC |
Given the problems enumerated above for which we'd like The Protocol to
provide information to recipients, there are a number of
scenarios that are not related to the problems that are to
be solved, per se, but the actual mechanics of
implementing/deploying the information service that The Protocol would provide.
TOC |
Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable for a domain holder to have the ability delegate to other entities the ability to sign for the domain holder. One obvious use scenario is a domain holder from a small domain that needs to have the ability for their outgoing ISP to sign all of their mail on behalf of the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions such as insurance benefits, etc.
TOC |
The Protocol's client will generally be deployed on incoming mail streams to provide the information as proposed in the problem scenarios. As such, it is envisioned that the RFC2822.From address would be used as a basis for the lookup. In particular, the domain part of the address would be consulted in some manner to fetch the published information. There is a fairly trivial attack against a naive use of this algorithm which is called the subdomain attack: that is, a domain needs to not only publish a policy for a given DNS label it controls, but it also may need to protect all subdomains of that label as well. If this characteristic is not met, an attacker would need only create a possibly fictitious subdomain which was not covered by The Protocol's information service
In widening the scope to have the possibility of all subdomains inherit the parent practice, a number of algorithms could be employed -- all seemingly with their own set of engineering tradeoffs. A common theme in the production of this draft was that the number of lookups, on average should be small, and that the discovery process should always be bound to some small finite number of queries.
TOC |
Resent mail is a common occurrence in many scenarios in the email world of today. For example, Alice sends a DKIM signed message with a published practice of signing all messages to Bob's mailing list. Bob, being a good net citizen, wants to be able to take his part of the responsibility of the message in question, so he DKIM signs the message, perhaps corresponding to the Sender address.
Note that this scenario is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wants to assert his part in the chain of accountability for the benefit of the ultimate receivers. It would be useful for this practice to be encouraged as it gives a more accurate view of who handled the message. It also has the side benefit that remailers that are not friendly to DKIM first party signatures (ie, break them) can be potentially assessed by the receiver based on the receiver's opinion of the signing domains that actually survived.
TOC |
As a practical matter, it may be difficult for a domain to roll out DKIM signing such that they can publish the DKIM Signing Complete practice given the complexities of the user population, outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail such as in Problem Scenario 2 must be classified to the least common denominator of the published practices. It would be desirable to allow a domain holder to publish a list of exceptions which would have a stronger practices statement.
For example, bigbank.example.com might be ready to say that statements@bigbank.example.com is always signed, but the rest of the domain, say, is not. Another situation is that the practices of some address local parts in a given domain are not the same as practices of other local parts. Using the same example of statements@bigbank.example.com being a transactional kind of email which would like to publish very strong practices, mixed in with the rest of the user population local parts which may go through mailing lists, etc, for which a less strong statement is appropriate.
It should be said that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in order to publish a strong practice, one only has to segregate those cases into different subdomains. For example: *@accounts.bigbank.example.com would publish a strong practice while *@bigbank.example.com could publish a more permissive practice.
TOC |
Email service provides an any-any mesh of potential connections: all that is required is the publication of an MX record and a SMTP listener to receive mail. Thus the use of The Protocol is likely to fall into two main scenarios, the first of which are large, well known domains who are in constant contact with one another. In this case caching of records is essential for performance, including the caching of the non-existence of records (ie, negative caching).
The second main scenario is when a domain exchanges mail with a much smaller volume domain. This scenario can be both perfectly normal as with the case of vanity domains, and sadly a vector for those sending mail for anti-social reasons. In this case we'd like the burden to The Protocol querier to be low, since many of the lookups will not provide a useful answer. Likewise, it would be advantageous to have upstream caching here as well so that, say, a mailing list exploder on a small domain does not result in an explosion of queries back at the root server for the small domain.
TOC |
While The Protocol records are likely to be primarily consumed by an automaton, for the foreseeable future they are also likely to be inspected by hand. It would be nice to have the practices stated in a fashion which is also intuitive to the human inspectors.
[Author's $.02: it's been amply demonstrated that simple human readable labels are often misconstrued. Opaque symbols do have the advantage that you need to consult the definition to determine its meaning rather than just intuiting what it "ought" to mean. /mat]
TOC |
There is a downgrade attack possible where a DKIM signature is hashed with a previously acceptable but now insecure hash algorithm. This could allow attackers to send their chosen text which is apparently signed by the targeted domain. It would be advantageous for a domain to publish what the allowable signing/hashing algorithms are to prevent this downgrade attack.
TOC |
While this document pertains only to requirements surrounding DKIM signing practices, it would be beneficial for the protocol to be able to extend to other protocols.
TOC |
The protocol must be able to withstand life in a hostile open internet environment. These include DoS attacks, and especially DoS attacks that leverage themselves through amplification inherent in the protocol. In addition, while a useful protocol may be built without strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols.
TOC |
This section defines the requirements for The Protocol. As with most requirements drafts, these requirements define the MINIMUM requirements that a candidate protocol must provide. It should also be noted that The Protocol must fulfill all of the requirements.
[Informative Note: it's not clear to the author that all of the provisional requirements can fulfill the harder requirements. If this is determined to be true, the provisional requirement should either be dropped or the harder requirements revised]
TOC |
Receivers need a means of obtaining information about a sender's DKIM practices. This requires a means of discovering where the information is and what it contains.
[Informative Note: this, for all intents and purposes is a prohibition on anything that might produce loops or result in extended delays and overhead; also though "deterministic" doesn't specify how many exchanges, the expectation is "few".]
[Refs: Deployment Scenario 2]
[Informative note: An example of ambiguity is sharing resource record types within a common DNS leaf. Hence, uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous reference.]
[Refs: Deployment Scenario 2]
TOC |
[Refs: Deployment Scenario 5, 8]
[Refs: Deployment Scenario 5]
[Refs: Deployment Scenario 5]
[Refs: Deployment Scenario 5, 8]
TOC |
In this section, a Practice is defined as a true statement according to the [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.).From domain holder of its intended externally visible behavior. An Expectation combines with a Practice to convey what the domain holder considers the likely outcome of the survivability of the Practice for a receiver. For example, a Practice that X is true when it leaves the domain, and an Expectation that it will|will-not|may|may-not remain true for some/all receivers.
[Refs: Problem Scenario 1,2]
[Refs: Problem Scenario 3]
[INFORMATIVE NOTE: there seems to be widespread consensus that a "neutral" or "I sign some mail" practice is useless to receivers. However, a null practice may help to cut short the policy lookup mechanism if it's published, and if that's the case it seems worthwhile. Also, a null policy may have some forensic utility, such as gaging the number of domains considering/using DKIM for example.]
[Refs: Deployment Scenario 2]
[Refs: Problem Scenario 1]
[Refs: Problem Scenario 2]
[Refs: Deployment Scenario 6]
[INFORMATIVE NOTE: this requirement seems to have rather weak support. It's mainly been added so that it can be issue-tracked. /mat]
[Refs: Deployment Scenario 4]
[Refs: Problem Scenario 1, 2, 3]
[INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.]
[Refs: Problem Scenario 1-2]
[Refs: Deployment Scenario 2]
[Refs: Deployment Scenario 7]
[INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver.]
[Refs: Deployment Scenario 3]
TOC |
[Refs: Deployment Scenario 8]
[Refs: Deployment Scenario 8]
TOC |
[Author's question: is it really O(1)? or O(n)?]
[Refs: Deployment Scenario 9]
[Refs: Deployment Scenario 9]
TOC |
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
TOC |
This draft defines requirements for a new protocol and the security related requirements are defined above. There is an expectation that The Protocol will not always be required to have source authentication of the practices information which is noteworthy.
TOC |
Due to flipping in the market and raising interest rates, this home is no longer free. Dave Crocker and Jim Fenton helped me raise the walls on this draft and are accorded a room at the inn. The inn is not yet full, however.
TOC |
TOC |
[I-D.ietf-dkim-base] | Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” draft-ietf-dkim-base-04 (work in progress), July 2006. |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[RFC2822] | Resnick, P., “Internet Message Format,” RFC 2822, April 2001. |
TOC |
[I-D.ietf-dkim-overview] | Hansen, T., “DomainKeys Identified Mail (DKIM) Service Overview,” draft-ietf-dkim-overview-01 (work in progress), June 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. |
TOC |
Michael Thomas | |
Cisco Systems | |
606 Sanchez St | |
San Francisco, California 94114 | |
USA | |
Phone: | +1-408-525-5386 |
Fax: | +1-408-525-5386 |
Email: | mat@cisco.com |
TOC |
Copyright © 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.
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).