--- 1/draft-ietf-dkim-rfc4871bis-14.txt 2011-07-11 20:16:22.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-15.txt 2011-07-11 20:16:22.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871, 5672 T. Hansen, Ed. (if approved) AT&T Laboratories Intended status: Standards Track M. Kucherawy, Ed. -Expires: January 3, 2012 Cloudmark - July 2, 2011 +Expires: January 12, 2012 Cloudmark + July 11, 2011 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-14 + draft-ietf-dkim-rfc4871bis-15 Abstract DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on January 3, 2012. + This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -138,26 +138,26 @@ 8.5. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 60 8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 8.8. Intentionally Malformed Key Records . . . . . . . . . . . 60 8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 61 8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 61 8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 8.14. Inappropriate Signing by Parent Domains . . . . . . . . . 61 - 8.15. Attacks Involving Addition of Header Fields . . . . . . . 62 + 8.15. Attacks Involving Extra Header Fields . . . . . . . . . . 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 - A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65 + A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 73 C.2. RFC4871 Compatibility . . . . . . . . . . . . . . . . . . 73 Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73 Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 74 @@ -1946,23 +1946,23 @@ 5.4.2. Signatures Involving Multiple Instances of a Field Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The - signer MAY include more instances of a header field name in h= than - there are actual corresponding header fields to indicate that - additional header fields of that name SHOULD NOT be added. + signer MAY include more instances of a header field name in "h=" than + there are actual corresponding header fields so that the signature + will not verify if additional header fields of that name are added. INFORMATIVE EXAMPLE: If the signer wishes to sign two existing Received header fields, and the existing header contains: Received: Received: Received: then the resulting DKIM-Signature header field should read: @@ -2765,62 +2765,70 @@ domain. INFORMATIVE NOTE: This is considered an acceptable risk for the same reason that it is acceptable for domain delegation. For example, in the example above any of the domains could potentially simply delegate "example.podunk.ca.us" to a server of their choice and completely replace all DNS-served information. Note that a verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1. -8.15. Attacks Involving Addition of Header Fields - - DKIM is able to sign and validate many types of messages that might - cause problems elsewhere in the message system. The message might - violate some part of [RFC5322], such as having multiple From: fields. - Equally, it might contain data that constitutes an attack on the - recipient, such as falsely indicating the name of the author. These - can represent serious attacks, but they have nothing to do with DKIM; - they are attacks on the recipient. +8.15. Attacks Involving Extra Header Fields Many email components, including MTAs, MSAs, MUAs and filtering modules, implement message format checks only loosely. This is done out of years of industry pressure to be liberal in what is accepted into the mail stream for the sake of reducing support costs; - improperly formed messages are often silently fixed in transit or - even delivered unrepaired. + improperly formed messages are often silently fixed in transit, + delivered unrepaired, or displayed inappropriately (e.g., by showing + only the first of multiple From: fields). + + Agents that evaluate or apply DKIM output need to be aware that a + DKIM signer can sign messages that are malformed (e.g., violate + [RFC5322], such as by having multiple instances of a field that is + only permitted once), or that become malformed in transit, or that + contain header or body content that is not true or valid. Use of + DKIM on such messages might constitute an attack against a receiver, + especially where additional credence is given to a signed message + without adequate evaluation of the signer. + + These can represent serious attacks, but they have nothing to do with + DKIM; they are attacks on the recipient, or on the wrongly identified + author. + + Moreover, an agent would be incorrect to infer that all instances of + a header field are signed just because one is. + + A genuine signature from the domain under attack can be obtained by + legitimate means, but extra header fields can then be added, either + by interception or by replay. In this scenario, DKIM can aid in + detecting addition of specific fields in transit. This is done by + having the signer list the field name(s) in the "h=" tag an extra + time (e.g., "h=from:from:..." for a message with one From field), so + that addition of an instance of that field downstream will render the + signature unable to be verified. (See Section 3.5 for details.) + This in essence is an explicit indication that the signer repudiates + responsibility for such a malformed message. DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the "d=" value) and, given the semantics of a DKIM signature, essentially the signer has taken some responsibility for a - problematic message. The verifier or receiver is able to act on this - information as needed, such as degrading the trust of the message - (or, indeed, of the signer). - - An agent consuming DKIM results needs to be aware that the validity - of any header field, signed or otherwise, is not guaranteed by DKIM. - - At the same time, DKIM can aid in detecting addition of specific - fields in transit. This is done by having the signer list the field - name(s) in the "h=" tag an extra time (e.g., "h=from:from:..." for a - message with one From field), so that addition of an instance of that - field downstream will render the signature unable to be verified. - - (See Section 3.5 for details.) This in essence is an explicit - indication that the signer does not wish to take any responsibility - for such a malformed message. + problematic message. It is up to the identity assessor or some other + subsequent agent to act on such messages as needed, such as degrading + the trust of the message (or, indeed, of the signer), or by warning + the recipient, or even refusing delivery. - Components of the mail system that perform loose enforcement of other - mail standards will need to revisit that posture when incorporating - DKIM, especially when considering matters of potential attacks on - receivers. + All components of the mail system that perform loose enforcement of + other mail standards will need to revisit that posture when + incorporating DKIM, especially when considering matters of potential + attacks such as those described. 9. References 9.1. Normative References [FIPS-180-3-2008] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-3, October 2008. [ITU-X660-1997]