Network Working Group M. Thomas Request for Comments: 5016 Cisco Systems Category: Informational October 2007 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractDomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD).
1. Introduction ....................................................2 2. Definitions and Requirements Language ...........................3 3. SSP Problem Scenarios ...........................................4 3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4 3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5 4. SSP Deployment Considerations ...................................6 4.1. Deployment Consideration 1: Outsourced Signing .............6 4.2. Deployment Consideration 2: Subdomain Coverage .............6 4.3. Deployment Consideration 3: Resent Original Mail ...........7 4.4. Deployment Consideration 4: Incremental Deployment of Signing .................................................7 4.5. Deployment Consideration 5: Performance and Caching ........8 4.6. Deployment Consideration 6: Human Legibility of Practices ..8 4.7. Deployment Consideration 7: Extensibility ..................8 4.8. Deployment Consideration 8: Security .......................8 5. Requirements ....................................................9 5.1. Discovery Requirements .....................................9 5.2. SSP Transport Requirements ................................10 5.3. Practice and Expectation Requirements .....................10 5.4. Extensibility and Forward Compatibility Requirements ......13 6. Requirements for SSP Security ..................................13 7. Security Considerations ........................................13 8. Acknowledgments ................................................13 9. References .....................................................14 9.1. Normative References ......................................14 RFC4871] defines a message level signing and verification mechanism for email. While a DKIM signed message speaks for itself, there is ambiguity if a message doesn't have a valid first party signature (i.e., on behalf of the [RFC2822].From address): is this to be expected or not? For email, this is an especially difficult problem since there is no expectation of a priori knowledge of a sending domain's practices. This ambiguity can be used to mount a bid down attack that is inherent with systems like email that allow optional authentication: if a receiver doesn't know otherwise, it should not assume that the lack of a valid signature is exceptional without other information. Thus, an attacker can take advantage of the ambiguity and simply not sign messages. 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 an unsigned piece of email.
This document defines the requirements for a mechanism that permits the publication of Sender Signing Practices (SSP). The document is organized into two main sections: first, a Problem and Deployment Scenario section that describes the problems that SSP is intended to address as well as the deployment issues surrounding the base problems, and the second section is the Requirements that arise because of those scenarios. RFC2822].From address in the message header; a first party address is also known as an Author address. o First Party Signature: a first party signature is a valid signature where the signing identity (the d= tag or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [RFC4871]. o Third Party Signature: a third party signature is a valid signature that does not qualify as a first party signature. Note that a DKIM third party signature is not required to correspond to a header field address such as the contents of Sender or List-Id, etc. o Practice: a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. o Expectation: an expectation combines with a practice to convey what the domain holder considers the likely survivability of the practice for a receiver, in particular receivers that may be more than one SMTP hop away. o DKIM Signing Complete: a practice where the domain holder asserts that all legitimate mail will be sent with a valid first party signature. 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 [RFC2119].
The following exchange illustrates problem scenario 1. 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken DKIM first party signature from Alice. 2. Domain Bob would like to know whether that is an expected state of affairs. 3. Domain Alice provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature. 4. Domain Bob could use this information to bias its filters to examine the message with some suspicion. RFC2822].From address in addition to spoofing much of the content to trick unsuspecting users into revealing sensitive information. Domain holders sending this mail would like the ability to give an enhanced guarantee that mail sent with their domain name should always arrive with the proof that the domain holder consented to its transmission. That is, the message should contain a valid first party signature as defined above. From a receiver's standpoint, knowing that a domain not only signs all of its mail, but places a very high value on the receipt of a valid first party signature from that domain is helpful. Hence, a receiver knows that the sending domain signs all its mail, and that the sending domain considers mail from this domain particularly sensitive in some sense, and is asking the receiver to be more suspicious than it otherwise might be of a broken or missing first- party signature. A receiver with the knowledge of the sender's expectations in hand might choose to process messages not conforming to the published practices in a special manner. Note that the ability to state an enhanced guarantee of a valid signature means that senders should expect mail that traverses modifying intermediaries (e.g., mailing lists, etc.) will likely be quarantined or deleted; thus, this scenario is more narrow than problem scenario 1. Informative Note: a receiving filter 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.
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken first party DKIM signature from domain Alice. 2. Domain Bob would like to know whether that is an expected state of affairs. 3. Domain Alice provides information that it signs all outgoing mail, and furthermore places an expectation that it should arrive with an intact first party signature, and that the receiver should be much more wary if it does not. 4. Domain Bob could use this information to bias its filters such that it examines the message with great suspicion. RFC2822].From will form the basis to fetch the published information. A trivial attack to circumvent finding the published information can be mounted by simply using a subdomain of the parent domain that doesn't have published information. This attack is called the subdomain attack: that is, a domain wants to not only publish a policy for a given DNS label it controls, but it would also like 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 that was not covered
by the SSP's information service. Thus, it would be advantageous for SSP to not only cover a given domain, but all subdomains of that domain as well.
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 constrained practices, while corporateusers.bigbank.example.com might publish more permissive practices.
strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols. RFC2822].From field. SSP's information is associated with the author's domain name, and is published subordinate to that domain name. 2. In order to limit the cost of its use, any query service supplying SSP's information MUST provide a definitive response within a small, deterministic number of message exchanges under normal operational conditions. 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 Considerations, Sections 4.2 and 4.5. 3. SSP's publishing mechanism MUST be defined such that it does not lead to multiple resource records of the same type for different protocols residing at the same location. Informative note: an example is multiple resource record of the same type within a common DNS leaf. Hence, uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous referencing. Refs: Deployment Consideration, Section 4.2.
4. SSP retrieval SHOULD provide coverage for not only a given domain but all of its subdomains as well. It is recognized that there is some reasonable doubt about the feasibility of a widely accepted solution to this requirement. If the working group does not achieve rough consensus on a solution, it MUST document the relevant security considerations in the protocol specification. Refs: Deployment Considerations, Sections 4.2 and 4.5. Sections 4.5 and 4.7. 2. The query/response in terms of latency time and the number of messages involved MUST be low (less than three message exchanges not counting retransmissions or other exceptional conditions). Refs: Deployment Consideration, Section 4.5. 3. If the infrastructure doesn't provide caching (a la DNS), the records retrieved MUST provide initiators the ability to maintain their own cache. The existing caching infrastructure is, however, highly desirable. Refs: Deployment Consideration, Section 4.5. 4. Multiple geographically and topologically diverse servers MUST be supported for high availability. Refs: Deployment Considerations, Sections 4.5 and 4.7. RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. As an example, a practice might be defined such that all email messages will contain a DKIM signature corresponding to the [RFC2822].From address. Since there is a possibility of alteration between what a sender sends and a receiver examines, an expectation combines with a practice to
convey what the [RFC2822].From domain considers the likely outcome of the survivability of the practice at a receiver. For example, a practice that a valid DKIM for the [RFC2822].From address is present when it is sent from the domain, and an expectation that it will remain present and valid for all receivers whether topologically adjacent or not. 1. SSP MUST be able to make practices and expectation assertions about the domain part of a [RFC2822].From address in the context of DKIM. SSP will not make assertions about other addresses for DKIM at this time. Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 2. SSP MUST provide a concise linkage between the [RFC2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a first party signature. Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 3. SSP MUST be able to publish a practice that the domain's signing behavior is "DKIM Signing Complete". That is, all messages were transmitted with a valid first party signature. Refs: Problem Scenario 1, Section 3.1. 4. SSP MUST be able to publish an expectation that a verifiable first party DKIM signature should be expected on receipt of a message. Refs: Problem Scenario 2, Section 3.2. 5. Practices and expectations MUST be presented in SSP syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown. Refs: Deployment Consideration, Section 4.6. 6. Because DKIM uses DNS to store selectors, there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to an affiliated party of the domain holder's choosing. That is, the domain holder may set an NS record for _domainkey.example.com to delegate to an email provider who manages the entire namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com
to a third party to constrain the third party to only be able to produce valid signatures in the benefits.example.com subdomain. Last, a domain holder can even use CNAME's to delegate individual leaf nodes. Given the above considerations, SSP need not invent a different means of allowing affiliated parties to sign on a domain's behalf at this time. Refs: Deployment Consideration, Section 4.4. 7. Practices and expectations MUST be presented as an information service from the signing domain to be consumed as an added factor to the receiver's local policy. In particular, a practice or expectation MUST NOT mandate any disposition stance on the receiver. Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 8. There is no requirement that SSP publish practices of any/all third parties that MUST NOT sign on the domain holder's behalf. This should be considered out of scope. INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository. Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 9. SSP MUST NOT be required to be invoked if a valid first party signature is found. Refs: Deployment Consideration, Section 4.2. 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. 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 Consideration, Section 4.3.
Section 4.7. 2. SSP MUST be able to add new practices and expectations within the existing discovery/transport/practices in a backward compatible fashion. Refs: Deployment Consideration, Section 4.7. Section 4.8. 3. SSP MUST have the ability for a domain holder to provide SSP's data such that a receiver can determine that it is authentically from the domain holder with a large degree of certainty. SSP may provide means that provide less certainty in trade off for ease of deployment. Refs: Deployment Consideration, Section 4.8. RFC4686] will be applicable.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 email@example.com.