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/ |