draft-ietf-dkim-rfc4871bis-14.txt   draft-ietf-dkim-rfc4871bis-15.txt 
Network Working Group D. Crocker, Ed. Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871, 5672 T. Hansen, Ed. Obsoletes: 4871, 5672 T. Hansen, Ed.
(if approved) AT&T Laboratories (if approved) AT&T Laboratories
Intended status: Standards Track M. Kucherawy, Ed. Intended status: Standards Track M. Kucherawy, Ed.
Expires: January 3, 2012 Cloudmark Expires: January 12, 2012 Cloudmark
July 2, 2011 July 11, 2011
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-14 draft-ietf-dkim-rfc4871bis-15
Abstract Abstract
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the responsibility for a message by associating the domain with the
message. This can be an author's organization, an operational relay message. This can be an author's organization, an operational relay
or one of their agents. DKIM separates the question of the identity or one of their agents. DKIM separates the question of the identity
of the signer of the message from the purported author of the of the signer of the message from the purported author of the
message. Assertion of responsibility is validated through a message. Assertion of responsibility is validated through a
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 31 skipping to change at page 4, line 31
8.5. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 8.5. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59
8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 60 8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 60
8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60
8.8. Intentionally Malformed Key Records . . . . . . . . . . . 60 8.8. Intentionally Malformed Key Records . . . . . . . . . . . 60
8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 61 8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 61
8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 61 8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 61
8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61
8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 61
8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61
8.14. Inappropriate Signing by Parent Domains . . . . . . . . . 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63
9.2. Informative References . . . . . . . . . . . . . . . . . . 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 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.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66
A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 A.3. The Email Signature is Verified . . . . . . . . . . . . . 67
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 73 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 73
C.2. RFC4871 Compatibility . . . . . . . . . . . . . . . . . . 73 C.2. RFC4871 Compatibility . . . . . . . . . . . . . . . . . . 73
Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73 Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73
Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 74 Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 74
skipping to change at page 45, line 8 skipping to change at page 45, line 8
5.4.2. Signatures Involving Multiple Instances of a Field 5.4.2. Signatures Involving Multiple Instances of a Field
Signers choosing to sign an existing header field that occurs more Signers choosing to sign an existing header field that occurs more
than once in the message (such as Received) MUST sign the physically than once in the message (such as Received) MUST sign the physically
last instance of that header field in the header block. Signers last instance of that header field in the header block. Signers
wishing to sign multiple instances of such a header field MUST wishing to sign multiple instances of such a header field MUST
include the header field name multiple times in the h= tag of the include the header field name multiple times in the h= tag of the
DKIM-Signature header field, and MUST sign such header fields in DKIM-Signature header field, and MUST sign such header fields in
order from the bottom of the header field block to the top. The 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 signer MAY include more instances of a header field name in "h=" than
there are actual corresponding header fields to indicate that there are actual corresponding header fields so that the signature
additional header fields of that name SHOULD NOT be added. will not verify if additional header fields of that name are added.
INFORMATIVE EXAMPLE: INFORMATIVE EXAMPLE:
If the signer wishes to sign two existing Received header fields, If the signer wishes to sign two existing Received header fields,
and the existing header contains: and the existing header contains:
Received: <A> Received: <A>
Received: <B> Received: <B>
Received: <C> Received: <C>
then the resulting DKIM-Signature header field should read: then the resulting DKIM-Signature header field should read:
skipping to change at page 62, line 19 skipping to change at page 62, line 19
domain. domain.
INFORMATIVE NOTE: This is considered an acceptable risk for the INFORMATIVE NOTE: This is considered an acceptable risk for the
same reason that it is acceptable for domain delegation. For same reason that it is acceptable for domain delegation. For
example, in the example above any of the domains could potentially example, in the example above any of the domains could potentially
simply delegate "example.podunk.ca.us" to a server of their choice simply delegate "example.podunk.ca.us" to a server of their choice
and completely replace all DNS-served information. Note that a and completely replace all DNS-served information. Note that a
verifier MAY ignore signatures that come from an unlikely domain verifier MAY ignore signatures that come from an unlikely domain
such as ".com", as discussed in Section 6.1.1. such as ".com", as discussed in Section 6.1.1.
8.15. Attacks Involving Addition of Header Fields 8.15. Attacks Involving Extra 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.
Many email components, including MTAs, MSAs, MUAs and filtering Many email components, including MTAs, MSAs, MUAs and filtering
modules, implement message format checks only loosely. This is done modules, implement message format checks only loosely. This is done
out of years of industry pressure to be liberal in what is accepted out of years of industry pressure to be liberal in what is accepted
into the mail stream for the sake of reducing support costs; into the mail stream for the sake of reducing support costs;
improperly formed messages are often silently fixed in transit or improperly formed messages are often silently fixed in transit,
even delivered unrepaired. 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. 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 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, domain (the "d=" value) and, given the semantics of a DKIM signature,
essentially the signer has taken some responsibility for a essentially the signer has taken some responsibility for a
problematic message. The verifier or receiver is able to act on this problematic message. It is up to the identity assessor or some other
information as needed, such as degrading the trust of the message subsequent agent to act on such messages as needed, such as degrading
(or, indeed, of the signer). the trust of the message (or, indeed, of the signer), or by warning
the recipient, or even refusing delivery.
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.
Components of the mail system that perform loose enforcement of other All components of the mail system that perform loose enforcement of
mail standards will need to revisit that posture when incorporating other mail standards will need to revisit that posture when
DKIM, especially when considering matters of potential attacks on incorporating DKIM, especially when considering matters of potential
receivers. attacks such as those described.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-180-3-2008] [FIPS-180-3-2008]
U.S. Department of Commerce, "Secure Hash Standard", FIPS U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-3, October 2008. PUB 180-3, October 2008.
[ITU-X660-1997] [ITU-X660-1997]
 End of changes. 10 change blocks. 
40 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/