draft-ietf-dkim-rfc4871bis-13.txt | draft-ietf-dkim-rfc4871bis-14.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: December 26, 2011 Cloudmark | Expires: January 3, 2012 Cloudmark | |||
June 24, 2011 | July 2, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-13 | draft-ietf-dkim-rfc4871bis-14 | |||
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 December 26, 2011. | This Internet-Draft will expire on January 3, 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 3, line 31 | skipping to change at page 3, line 31 | |||
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | 2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | |||
2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | 2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | |||
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 | 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 | 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 | |||
3.3. Signing and Verification Algorithms . . . . . . . . . . . 14 | 3.3. Signing and Verification Algorithms . . . . . . . . . . . 14 | |||
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | |||
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | |||
3.6. Key Management and Representation . . . . . . . . . . . . 29 | 3.6. Key Management and Representation . . . . . . . . . . . . 28 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32 | |||
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 36 | 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 34 | |||
3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 36 | 3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 35 | |||
3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 | 3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 | |||
3.11. Relationship between SDID and AUID . . . . . . . . . . . . 36 | 3.11. Relationship between SDID and AUID . . . . . . . . . . . . 36 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 | 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 | |||
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | |||
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 39 | 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 40 | 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.1. Determine Whether the Email Should Be Signed and by | 5.1. Determine Whether the Email Should Be Signed and by | |||
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.2. Select a Private Key and Corresponding Selector | 5.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 40 | Information . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.3. Normalize the Message to Prevent Transport Conversions . . 41 | 5.3. Normalize the Message to Prevent Transport Conversions . . 40 | |||
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 42 | 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | |||
5.5. Recommended Signature Content . . . . . . . . . . . . . . 44 | 5.5. Compute the Message Hash and Signature . . . . . . . . . . 45 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 45 | 5.6. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 46 | ||||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
6.1. Extract Signatures from the Message . . . . . . . . . . . 47 | 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | |||
6.2. Communicate Verification Results . . . . . . . . . . . . . 52 | 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | |||
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 | ||||
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 54 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 55 | 7.1. Email Authentication Methods Registry . . . . . . . . . . 53 | |||
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 55 | 7.2. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | |||
7.4. _domainkey DNS TXT Resource Record Tag Specifications . . 56 | 7.3. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | |||
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | 7.4. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | |||
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 57 | 7.5. _domainkey DNS TXT Resource Record Tag Specifications . . 55 | |||
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 57 | 7.6. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | |||
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | 7.7. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | |||
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 58 | 7.8. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 58 | 7.9. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | |||
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 58 | 7.10. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | |||
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | |||
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | 8.1. ASCII Art Attacks . . . . . . . . . . . . . . . . . . . . 57 | |||
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | 8.2. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 58 | |||
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 | 8.3. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | |||
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 | 8.4. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | |||
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 | 8.5. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | 8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 60 | |||
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | 8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 | |||
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | 8.8. Intentionally Malformed Key Records . . . . . . . . . . . 60 | |||
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | 8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | |||
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62 | 8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | |||
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 | 8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | |||
8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | 8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | |||
8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 | 8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | 8.14. Inappropriate Signing by Parent Domains . . . . . . . . . 61 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | 8.15. Attacks Involving Addition of Header Fields . . . . . . . 62 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 65 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 | |||
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 | |||
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 | |||
A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 | |||
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 | |||
C.2. RFC4871 Compatibility . . . . . . . . . . . . . . . . . . 74 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 | |||
Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 74 | C.1. Compatibility with DomainKeys Key Records . . . . . . . . 73 | |||
Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 75 | C.2. RFC4871 Compatibility . . . . . . . . . . . . . . . . . . 73 | |||
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 77 | Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 | Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 74 | |||
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 76 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 | ||||
1. Introduction | 1. Introduction | |||
DomainKeys Identified Mail (DKIM) permits a person, role, or | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
organization to claim some responsibility for a message by | organization to claim some responsibility for a message by | |||
associating a domain name [RFC1034] with the message [RFC5322], which | associating a domain name [RFC1034] with the message [RFC5322], which | |||
they are authorized to use. This can be an author's organization, an | they are authorized to use. This can be an author's organization, an | |||
operational relay or one of their agents. Assertion of | operational relay or one of their agents. Assertion of | |||
responsibility is validated through a cryptographic signature and | responsibility is validated through a cryptographic signature and | |||
querying the signer's domain directly to retrieve the appropriate | querying the signer's domain directly to retrieve the appropriate | |||
skipping to change at page 6, line 33 | skipping to change at page 6, line 33 | |||
field. | field. | |||
INFORMATIVE RATIONALE: The signing identity specified by a DKIM | INFORMATIVE RATIONALE: The signing identity specified by a DKIM | |||
signature is not required to match an address in any particular | signature is not required to match an address in any particular | |||
header field because of the broad methods of interpretation by | header field because of the broad methods of interpretation by | |||
recipient mail systems, including MUAs. | recipient mail systems, including MUAs. | |||
1.3. Scalability | 1.3. Scalability | |||
DKIM is designed to support the extreme scalability requirements that | DKIM is designed to support the extreme scalability requirements that | |||
characterize the email identification problem. There are currently | characterize the email identification problem. There are many | |||
over 70 million domains and a much larger number of individual | millions of domains and a much larger number of individual addresses. | |||
addresses. DKIM seeks to preserve the positive aspects of the | DKIM seeks to preserve the positive aspects of the current email | |||
current email infrastructure, such as the ability for anyone to | infrastructure, such as the ability for anyone to communicate with | |||
communicate with anyone else without introduction. | anyone else without introduction. | |||
1.4. Simple Key Management | 1.4. Simple Key Management | |||
DKIM differs from traditional hierarchical public-key systems in that | DKIM differs from traditional hierarchical public-key systems in that | |||
no Certificate Authority infrastructure is required; the verifier | no Certificate Authority infrastructure is required; the verifier | |||
requests the public key from a repository in the domain of the | requests the public key from a repository in the domain of the | |||
claimed signer directly rather than from a third party. | claimed signer directly rather than from a third party. | |||
The DNS is proposed as the initial mechanism for the public keys. | The DNS is proposed as the initial mechanism for the public keys. | |||
Thus, DKIM currently depends on DNS administration and the security | Thus, DKIM currently depends on DNS administration and the security | |||
skipping to change at page 8, line 33 | skipping to change at page 8, line 33 | |||
of it. For DKIM processing, the domain name portion of the AUID has | of it. For DKIM processing, the domain name portion of the AUID has | |||
only basic domain name semantics; any possible owner-specific | only basic domain name semantics; any possible owner-specific | |||
semantics are outside the scope of DKIM. It is specified in | semantics are outside the scope of DKIM. It is specified in | |||
Section 3.5. | Section 3.5. | |||
Note that acceptable values for the AUID may be constrained via a | Note that acceptable values for the AUID may be constrained via a | |||
flag in the public key record. (See Section 3.6.1.) | flag in the public key record. (See Section 3.6.1.) | |||
2.7. Identity Assessor | 2.7. Identity Assessor | |||
A module that consumes DKIM's mandatory payload, which is the | An element in the mail system that consumes DKIM's payload, which is | |||
responsible Signing Domain Identifier (SDID). The module is | the responsible Signing Domain Identifier (SDID). The Identity | |||
dedicated to the assessment of the delivered identifier. Other DKIM | Assessor is dedicated to the assessment of the delivered identifier. | |||
(and non-DKIM) values can also be delivered to this module as well as | Other DKIM (and non-DKIM) values can also be used by the Identity | |||
to a more general message evaluation filtering engine. However, this | Assessor (if they are available) to provide a more general message | |||
additional activity is outside the scope of the DKIM signature | evaluation filtering engine. However, this additional activity is | |||
specification. | outside the scope of the DKIM signature specification. | |||
2.8. Whitespace | 2.8. Whitespace | |||
There are three forms of whitespace: | There are three forms of whitespace: | |||
o WSP represents simple whitespace, i.e., a space or a tab character | o WSP represents simple whitespace, i.e., a space or a tab character | |||
(formal definition in [RFC5234]). | (formal definition in [RFC5234]). | |||
o LWSP is linear whitespace, defined as WSP plus CRLF (formal | o LWSP is linear whitespace, defined as WSP plus CRLF (formal | |||
definition in [RFC5234]). | definition in [RFC5234]). | |||
skipping to change at page 10, line 34 | skipping to change at page 10, line 34 | |||
long lines; such whitespace is NOT part of the value, and MUST be | long lines; such whitespace is NOT part of the value, and MUST be | |||
removed before decoding. Use of characters not listed as "mail-safe" | removed before decoding. Use of characters not listed as "mail-safe" | |||
in [RFC2049] is NOT RECOMMENDED. | in [RFC2049] is NOT RECOMMENDED. | |||
ABNF: | ABNF: | |||
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) | dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) | |||
; hex-octet is from RFC2045 | ; hex-octet is from RFC2045 | |||
dkim-safe-char = %x21-3A / %x3C / %x3E-7E | dkim-safe-char = %x21-3A / %x3C / %x3E-7E | |||
; '!' - ':', '<', '>' - '~' | ; '!' - ':', '<', '>' - '~' | |||
; Characters not listed as "mail-safe" in | ||||
; [RFC2049] are also NOT RECOMMENDED. | ||||
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- | INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- | |||
Printable as defined in [RFC2045] in several important ways: | Printable as defined in [RFC2045] in several important ways: | |||
1. Whitespace in the input text, including CR and LF, must be | 1. Whitespace in the input text, including CR and LF, must be | |||
encoded. [RFC2045] does not require such encoding, and does | encoded. [RFC2045] does not require such encoding, and does | |||
not permit encoding of CR or LF characters that are part of a | not permit encoding of CR or LF characters that are part of a | |||
CRLF line break. | CRLF line break. | |||
2. Whitespace in the encoded text is ignored. This is to allow | 2. Whitespace in the encoded text is ignored. This is to allow | |||
skipping to change at page 12, line 12 | skipping to change at page 12, line 12 | |||
implementation, this can be used to allow delegation of a portion of | implementation, this can be used to allow delegation of a portion of | |||
the selector namespace. | the selector namespace. | |||
ABNF: | ABNF: | |||
selector = sub-domain *( "." sub-domain ) | selector = sub-domain *( "." sub-domain ) | |||
The number of public keys and corresponding selectors for each domain | The number of public keys and corresponding selectors for each domain | |||
is determined by the domain owner. Many domain owners will be | is determined by the domain owner. Many domain owners will be | |||
satisfied with just one selector, whereas administratively | satisfied with just one selector, whereas administratively | |||
distributed organizations may choose to manage disparate selectors | distributed organizations can choose to manage disparate selectors | |||
and key pairs in different regions or on different email servers. | and key pairs in different regions or on different email servers. | |||
Beyond administrative convenience, selectors make it possible to | Beyond administrative convenience, selectors make it possible to | |||
seamlessly replace public keys on a routine basis. If a domain | seamlessly replace public keys on a routine basis. If a domain | |||
wishes to change from using a public key associated with selector | wishes to change from using a public key associated with selector | |||
"january2005" to a public key associated with selector | "january2005" to a public key associated with selector | |||
"february2005", it merely makes sure that both public keys are | "february2005", it merely makes sure that both public keys are | |||
advertised in the public-key repository concurrently for the | advertised in the public-key repository concurrently for the | |||
transition period during which email may be in transit prior to | transition period during which email may be in transit prior to | |||
verification. At the start of the transition period, the outbound | verification. At the start of the transition period, the outbound | |||
skipping to change at page 13, line 20 | skipping to change at page 13, line 20 | |||
Values are a series of strings containing either plain text, "base64" | Values are a series of strings containing either plain text, "base64" | |||
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, | text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, | |||
Section 6.7), or "dkim-quoted-printable" (as defined in | Section 6.7), or "dkim-quoted-printable" (as defined in | |||
Section 2.11). The name of the tag will determine the encoding of | Section 2.11). The name of the tag will determine the encoding of | |||
each value. Unencoded semicolon (";") characters MUST NOT occur in | each value. Unencoded semicolon (";") characters MUST NOT occur in | |||
the tag value, since that separates tag-specs. | the tag value, since that separates tag-specs. | |||
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | |||
below (as "tag-value") only includes 7-bit characters, an | below (as "tag-value") only includes 7-bit characters, an | |||
implementation that wished to anticipate future standards would be | implementation that wished to anticipate future standards would be | |||
advised not to preclude the use of UTF8-encoded text in tag=value | advised not to preclude the use of UTF8-encoded ([RFC3629]) text | |||
lists. | in tag=value lists. | |||
Formally, the ABNF syntax rules are as follows: | Formally, the ABNF syntax rules are as follows: | |||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | tag-list = tag-spec *( ";" tag-spec ) [ ";" ] | |||
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | |||
tag-name = ALPHA 0*ALNUMPUNC | tag-name = ALPHA *ALNUMPUNC | |||
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] | tag-value = [ tval *( 1*(WSP / FWS) tval ) ] | |||
; Prohibits WSP and FWS at beginning and end | ; Prohibits WSP and FWS at beginning and end | |||
tval = 1*VALCHAR | tval = 1*VALCHAR | |||
VALCHAR = %x21-3A / %x3C-7E | VALCHAR = %x21-3A / %x3C-7E | |||
; EXCLAMATION to TILDE except SEMICOLON | ; EXCLAMATION to TILDE except SEMICOLON | |||
ALNUMPUNC = ALPHA / DIGIT / "_" | ALNUMPUNC = ALPHA / DIGIT / "_" | |||
Note that WSP is allowed anywhere around tags. In particular, any | Note that WSP is allowed anywhere around tags. In particular, any | |||
WSP after the "=" and any WSP before the terminating ";" is not part | WSP after the "=" and any WSP before the terminating ";" is not part | |||
of the value; however, WSP inside the value is significant. | of the value; however, WSP inside the value is significant. | |||
skipping to change at page 15, line 9 | skipping to change at page 15, line 9 | |||
off-line attacks, signers MUST use RSA keys of at least 1024 bits for | off-line attacks, signers MUST use RSA keys of at least 1024 bits for | |||
long-lived keys. Verifiers MUST be able to validate signatures with | long-lived keys. Verifiers MUST be able to validate signatures with | |||
keys ranging from 512 bits to 2048 bits, and they MAY be able to | keys ranging from 512 bits to 2048 bits, and they MAY be able to | |||
validate signatures with larger keys. Verifier policies may use the | validate signatures with larger keys. Verifier policies may use the | |||
length of the signing key as one metric for determining whether a | length of the signing key as one metric for determining whether a | |||
signature is acceptable. | signature is acceptable. | |||
Factors that should influence the key size choice include the | Factors that should influence the key size choice include the | |||
following: | following: | |||
o The practical constraint that large (e.g., 4096 bit) keys may not | o The practical constraint that large (e.g., 4096 bit) keys might | |||
fit within a 512-byte DNS UDP response packet | not fit within a 512-byte DNS UDP response packet | |||
o The security constraint that keys smaller than 1024 bits are | o The security constraint that keys smaller than 1024 bits are | |||
subject to off-line attacks | subject to off-line attacks | |||
o Larger keys impose higher CPU costs to verify and sign email | o Larger keys impose higher CPU costs to verify and sign email | |||
o Keys can be replaced on a regular basis, thus their lifetime can | o Keys can be replaced on a regular basis, thus their lifetime can | |||
be relatively short | be relatively short | |||
o The security goals of this specification are modest compared to | o The security goals of this specification are modest compared to | |||
skipping to change at page 17, line 16 | skipping to change at page 17, line 16 | |||
separating the header field name from the header field value. The | separating the header field name from the header field value. The | |||
colon separator MUST be retained. | colon separator MUST be retained. | |||
3.4.3. The "simple" Body Canonicalization Algorithm | 3.4.3. The "simple" Body Canonicalization Algorithm | |||
The "simple" body canonicalization algorithm ignores all empty lines | The "simple" body canonicalization algorithm ignores all empty lines | |||
at the end of the message body. An empty line is a line of zero | at the end of the message body. An empty line is a line of zero | |||
length after removal of the line terminator. If there is no body or | length after removal of the line terminator. If there is no body or | |||
no trailing CRLF on the message body, a CRLF is added. It makes no | no trailing CRLF on the message body, a CRLF is added. It makes no | |||
other changes to the message body. In more formal terms, the | other changes to the message body. In more formal terms, the | |||
"simple" body canonicalization algorithm converts "0*CRLF" at the end | "simple" body canonicalization algorithm converts "*CRLF" at the end | |||
of the body to a single "CRLF". | of the body to a single "CRLF". | |||
Note that a completely empty or missing body is canonicalized as a | Note that a completely empty or missing body is canonicalized as a | |||
single "CRLF"; that is, the canonicalized length will be 2 octets. | single "CRLF"; that is, the canonicalized length will be 2 octets. | |||
The SHA-1 value (in base64) for an empty body (canonicalized to a | The SHA-1 value (in base64) for an empty body (canonicalized to a | |||
"CRLF") is: | "CRLF") is: | |||
uoq1oCgLlTqpdDX/iUbLy7J1Wic= | uoq1oCgLlTqpdDX/iUbLy7J1Wic= | |||
The SHA-256 value is: | The SHA-256 value is: | |||
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= | frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= | |||
skipping to change at page 18, line 4 | skipping to change at page 18, line 4 | |||
line" is defined in Section 3.4.3. If the body is non-empty, but | line" is defined in Section 3.4.3. If the body is non-empty, but | |||
does not end with a CRLF, a CRLF is added. (For email, this is | does not end with a CRLF, a CRLF is added. (For email, this is | |||
only possible when using extensions to SMTP or non-SMTP transport | only possible when using extensions to SMTP or non-SMTP transport | |||
mechanisms.) | mechanisms.) | |||
The SHA-1 value (in base64) for an empty body (canonicalized to a | The SHA-1 value (in base64) for an empty body (canonicalized to a | |||
null input) is: | null input) is: | |||
2jmj7l5rSw0yVb/vlWAYkK/YBwk= | 2jmj7l5rSw0yVb/vlWAYkK/YBwk= | |||
The SHA-256 value is: | The SHA-256 value is: | |||
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= | 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= | |||
INFORMATIVE NOTE: It should be noted that the relaxed body | ||||
canonicalization algorithm may enable certain types of extremely | ||||
crude "ASCII Art" attacks where a message may be conveyed by | ||||
adjusting the spacing between words. If this is a concern, the | ||||
"simple" body canonicalization algorithm should be used instead. | ||||
3.4.5. Body Length Limits | ||||
A body length count MAY be specified to limit the signature | ||||
calculation to an initial prefix of the body text, measured in | ||||
octets. If the body length count is not specified, the entire | ||||
message body is signed. | ||||
INFORMATIVE RATIONALE: This capability is provided because it is | ||||
very common for mailing lists to add trailers to messages (e.g., | ||||
instructions how to get off the list). Until those messages are | ||||
also signed, the body length count is a useful tool for the | ||||
verifier since it may as a matter of policy accept messages having | ||||
valid signatures with extraneous data. | ||||
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables | ||||
an attack in which an attacker modifies a message to include | ||||
content that solely benefits the attacker. It is possible for the | ||||
appended content to completely replace the original content in the | ||||
end recipient's eyes, such as via alterations to the MIME | ||||
structure or exploiting lax HTML parsing in the MUA, and to defeat | ||||
duplicate message detection algorithms. To avoid this attack, | ||||
signers should be wary of using this tag, and verifiers might wish | ||||
to ignore the tag, perhaps based on other criteria. | ||||
The body length count allows the signer of a message to permit data | 3.4.5. Canonicalization Examples (INFORMATIVE) | |||
to be appended to the end of the body of a signed message. The body | ||||
length count MUST be calculated following the canonicalization | ||||
algorithm; for example, any whitespace ignored by a canonicalization | ||||
algorithm is not included as part of the body length count. | ||||
A body length count of zero means that the body is completely | ||||
unsigned. | ||||
Signers wishing to ensure that no modification of any sort can occur | ||||
should specify the "simple" canonicalization algorithm for both | ||||
header and body and omit the body length count. | ||||
3.4.6. Canonicalization Examples (INFORMATIVE) | ||||
In the following examples, actual whitespace is used only for | In the following examples, actual whitespace is used only for | |||
clarity. The actual input and output text is designated using | clarity. The actual input and output text is designated using | |||
bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | |||
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | |||
For example, "X <SP> Y" and "X<SP>Y" represent the same three | For example, "X <SP> Y" and "X<SP>Y" represent the same three | |||
characters. | characters. | |||
Example 1: A message reading: | Example 1: A message reading: | |||
A: <SP> X <CRLF> | A: <SP> X <CRLF> | |||
skipping to change at page 20, line 32 | skipping to change at page 19, line 40 | |||
The encodings for each field type are listed below. Tags described | The encodings for each field type are listed below. Tags described | |||
as qp-section are encoded as described in Section 6.7 of MIME Part | as qp-section are encoded as described in Section 6.7 of MIME Part | |||
One [RFC2045], with the additional conversion of semicolon characters | One [RFC2045], with the additional conversion of semicolon characters | |||
to "=3B"; intuitively, this is one line of quoted-printable encoded | to "=3B"; intuitively, this is one line of quoted-printable encoded | |||
text. The dkim-quoted-printable syntax is defined in Section 2.11. | text. The dkim-quoted-printable syntax is defined in Section 2.11. | |||
Tags on the DKIM-Signature header field along with their type and | Tags on the DKIM-Signature header field along with their type and | |||
requirement status are shown below. Unrecognized tags MUST be | requirement status are shown below. Unrecognized tags MUST be | |||
ignored. | ignored. | |||
v= Version (MUST be included). This tag defines the version of this | v= Version (plain-text; REQUIRED). This tag defines the version of | |||
specification that applies to the signature record. It MUST have | this specification that applies to the signature record. It MUST | |||
the value "1". Note that verifiers must do a string comparison on | have the value "1" for implementations compliant with this version | |||
this value; for example, "1" is not the same as "1.0". | of DKIM. | |||
ABNF: | ABNF: | |||
sig-v-tag = %x76 [FWS] "=" [FWS] "1" | sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT | |||
INFORMATIVE NOTE: DKIM-Signature version numbers may increase | INFORMATIVE NOTE: DKIM-Signature version numbers may increase | |||
arithmetically as new versions of this specification are | arithmetically as new versions of this specification are | |||
released. | released. | |||
a= The algorithm used to generate the signature (plain-text; | a= The algorithm used to generate the signature (plain-text; | |||
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | |||
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | |||
description of the algorithms. | description of the algorithms. | |||
ABNF: | ABNF: | |||
skipping to change at page 23, line 20 | skipping to change at page 22, line 20 | |||
h= Signed header fields (plain-text, but see description; REQUIRED). | h= Signed header fields (plain-text, but see description; REQUIRED). | |||
A colon-separated list of header field names that identify the | A colon-separated list of header field names that identify the | |||
header fields presented to the signing algorithm. The field MUST | header fields presented to the signing algorithm. The field MUST | |||
contain the complete list of header fields in the order presented | contain the complete list of header fields in the order presented | |||
to the signing algorithm. The field MAY contain names of header | to the signing algorithm. The field MAY contain names of header | |||
fields that do not exist when signed; nonexistent header fields do | fields that do not exist when signed; nonexistent header fields do | |||
not contribute to the signature computation (that is, they are | not contribute to the signature computation (that is, they are | |||
treated as the null input, including the header field name, the | treated as the null input, including the header field name, the | |||
separating colon, the header field value, and any CRLF | separating colon, the header field value, and any CRLF | |||
terminator). The field MUST NOT include the DKIM-Signature header | terminator). The field MAY contain multiple instances of a header | |||
field that is being created or verified, but may include others. | field name, meaning multiple occurrences of the corresponding | |||
Folding whitespace (FWS) MAY be included on either side of the | header field are included in the header hash. The field MUST NOT | |||
colon separator. Header field names MUST be compared against | include the DKIM-Signature header field that is being created or | |||
actual header field names in a case-insensitive manner. This list | verified, but may include others. Folding whitespace (FWS) MAY be | |||
MUST NOT be empty. See Section 5.4 for a discussion of choosing | included on either side of the colon separator. Header field | |||
header fields to sign. | names MUST be compared against actual header field names in a | |||
case-insensitive manner. This list MUST NOT be empty. See | ||||
Section 5.4 for a discussion of choosing header fields to sign, | ||||
and Section 5.4.2 for requirements when signing multiple instances | ||||
of a single field. | ||||
ABNF: | ABNF: | |||
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | |||
0*( [FWS] ":" [FWS] hdr-name ) | *( [FWS] ":" [FWS] hdr-name ) | |||
INFORMATIVE EXPLANATION: By "signing" header fields that do not | INFORMATIVE EXPLANATION: By "signing" header fields that do not | |||
actually exist, a signer can allow a verifier to detect | actually exist, a signer can allow a verifier to detect | |||
insertion of those header fields after signing. However, since | insertion of those header fields after signing. However, since | |||
a signer cannot possibly know what header fields might be | a signer cannot possibly know what header fields might be | |||
created in the future, and that some MUAs might present header | defined in the future, this mechanism can't be used to prevent | |||
fields that are embedded inside a message (e.g., as a message/ | the addition of any possible unknown header fields. | |||
rfc822 content type), the security of this solution is not | ||||
total. | ||||
INFORMATIVE EXPLANATION: The exclusion of the header field name | INFORMATIVE NOTE: "Signing" fields that are not present at the | |||
and colon as well as the header field value for non-existent | time of signing not only prevents fields and values from being | |||
header fields allows detection of an attacker that inserts an | added, but also prevents adding fields with no values. | |||
actual header field with a null value. | ||||
i= The Agent or User Identifier (AUID) on behalf of which the SDID is | i= The Agent or User Identifier (AUID) on behalf of which the SDID is | |||
taking responsibility (dkim-quoted-printable; OPTIONAL, default is | taking responsibility (dkim-quoted-printable; OPTIONAL, default is | |||
an empty Local-part followed by an "@" followed by the domain from | an empty Local-part followed by an "@" followed by the domain from | |||
the "d=" tag). | the "d=" tag). | |||
The syntax is a standard email address where the Local-part MAY be | The syntax is a standard email address where the Local-part MAY be | |||
omitted. The domain part of the address MUST be the same as, or a | omitted. The domain part of the address MUST be the same as, or a | |||
subdomain of, the value of the "d=" tag. | subdomain of, the value of the "d=" tag. | |||
skipping to change at page 25, line 28 | skipping to change at page 24, line 29 | |||
what extent a typical end-user recipient can rely on any | what extent a typical end-user recipient can rely on any | |||
assurances that might be made by successful use of the "i=" | assurances that might be made by successful use of the "i=" | |||
options. | options. | |||
l= Body length count (plain-text unsigned decimal integer; OPTIONAL, | l= Body length count (plain-text unsigned decimal integer; OPTIONAL, | |||
default is entire body). This tag informs the verifier of the | default is entire body). This tag informs the verifier of the | |||
number of octets in the body of the email after canonicalization | number of octets in the body of the email after canonicalization | |||
included in the cryptographic hash, starting from 0 immediately | included in the cryptographic hash, starting from 0 immediately | |||
following the CRLF preceding the body. This value MUST NOT be | following the CRLF preceding the body. This value MUST NOT be | |||
larger than the actual number of octets in the canonicalized | larger than the actual number of octets in the canonicalized | |||
message body. | message body. See further discussion in Section 8.2. | |||
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might | ||||
allow display of fraudulent content without appropriate warning | ||||
to end users. The "l=" tag is intended for increasing | ||||
signature robustness when sending to mailing lists that both | ||||
modify their content and do not sign their messages. However, | ||||
using the "l=" tag enables attacks in which an intermediary | ||||
with malicious intent modifies a message to include content | ||||
that solely benefits the attacker. It is possible for the | ||||
appended content to completely replace the original content in | ||||
the end recipient's eyes and to defeat duplicate message | ||||
detection algorithms. Examples are described in Security | ||||
Considerations (Section 8). To avoid this attack, signers | ||||
should be extremely wary of using this tag, and assessors might | ||||
wish to ignore signatures that use the tag. | ||||
INFORMATIVE NOTE: The value of the "l=" tag is constrained to | INFORMATIVE NOTE: The value of the "l=" tag is constrained to | |||
76 decimal digits. This constraint is not intended to predict | 76 decimal digits. This constraint is not intended to predict | |||
the size of future messages or to require implementations to | the size of future messages or to require implementations to | |||
use an integer representation large enough to represent the | use an integer representation large enough to represent the | |||
maximum possible value, but is intended to remind the | maximum possible value, but is intended to remind the | |||
implementer to check the length of this and all other tags | implementer to check the length of this and all other tags | |||
during verification and to test for integer overflow when | during verification and to test for integer overflow when | |||
decoding the value. Implementers may need to limit the actual | decoding the value. Implementers may need to limit the actual | |||
value expressed to a value smaller than 10^76, e.g., to allow a | value expressed to a value smaller than 10^76, e.g., to allow a | |||
skipping to change at page 30, line 27 | skipping to change at page 29, line 15 | |||
allowing all algorithms). A colon-separated list of hash | allowing all algorithms). A colon-separated list of hash | |||
algorithms that might be used. Unrecognized algorithms MUST be | algorithms that might be used. Unrecognized algorithms MUST be | |||
ignored. Refer to Section 3.3 for a discussion of the hash | ignored. Refer to Section 3.3 for a discussion of the hash | |||
algorithms implemented by Signers and Verifiers. The set of | algorithms implemented by Signers and Verifiers. The set of | |||
algorithms listed in this tag in each record is an operational | algorithms listed in this tag in each record is an operational | |||
choice made by the Signer. | choice made by the Signer. | |||
ABNF: | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | |||
0*( [FWS] ":" [FWS] key-h-tag-alg ) | *( [FWS] ":" [FWS] key-h-tag-alg ) | |||
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg | key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg | |||
x-key-h-tag-alg = hyphenated-word ; for future extension | x-key-h-tag-alg = hyphenated-word ; for future extension | |||
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | |||
verifiers MUST support the "rsa" key type. The "rsa" key type | verifiers MUST support the "rsa" key type. The "rsa" key type | |||
indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | |||
[RFC3447] (see Sections Section 3.1 and A.1.1) is being used in | [RFC3447] (see Sections Section 3.1 and A.1.1) is being used in | |||
the "p=" tag. (Note: the "p=" tag further encodes the value using | the "p=" tag. (Note: the "p=" tag further encodes the value using | |||
the base64 algorithm.) Unrecognized key types MUST be ignored. | the base64 algorithm.) Unrecognized key types MUST be ignored. | |||
skipping to change at page 32, line 16 | skipping to change at page 31, line 8 | |||
email electronic mail (not necessarily limited to SMTP) | email electronic mail (not necessarily limited to SMTP) | |||
This tag is intended to constrain the use of keys for other | This tag is intended to constrain the use of keys for other | |||
purposes, should use of DKIM be defined by other services in the | purposes, should use of DKIM be defined by other services in the | |||
future. | future. | |||
ABNF: | ABNF: | |||
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type | key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type | |||
0*( [FWS] ":" [FWS] key-s-tag-type ) | *( [FWS] ":" [FWS] key-s-tag-type ) | |||
key-s-tag-type = "email" / "*" / x-key-s-tag-type | key-s-tag-type = "email" / "*" / x-key-s-tag-type | |||
x-key-s-tag-type = hyphenated-word ; for future extension | x-key-s-tag-type = hyphenated-word ; for future extension | |||
t= Flags, represented as a colon-separated list of names (plain- | t= Flags, represented as a colon-separated list of names (plain- | |||
text; OPTIONAL, default is no flags set). Unrecognized flags MUST | text; OPTIONAL, default is no flags set). Unrecognized flags MUST | |||
be ignored. The defined flags are as follows: | be ignored. The defined flags are as follows: | |||
y This domain is testing DKIM. Verifiers MUST NOT treat messages | y This domain is testing DKIM. Verifiers MUST NOT treat messages | |||
from signers in testing mode differently from unsigned email, even | from signers in testing mode differently from unsigned email, even | |||
should the signature fail to verify. Verifiers MAY wish to track | should the signature fail to verify. Verifiers MAY wish to track | |||
skipping to change at page 32, line 38 | skipping to change at page 31, line 30 | |||
s Any DKIM-Signature header fields using the "i=" tag MUST have the | s Any DKIM-Signature header fields using the "i=" tag MUST have the | |||
same domain value on the right-hand side of the "@" in the "i=" | same domain value on the right-hand side of the "@" in the "i=" | |||
tag and the value of the "d=" tag. That is, the "i=" domain MUST | tag and the value of the "d=" tag. That is, the "i=" domain MUST | |||
NOT be a subdomain of "d=". Use of this flag is RECOMMENDED | NOT be a subdomain of "d=". Use of this flag is RECOMMENDED | |||
unless subdomaining is required. | unless subdomaining is required. | |||
ABNF: | ABNF: | |||
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | |||
0*( [FWS] ":" [FWS] key-t-tag-flag ) | *( [FWS] ":" [FWS] key-t-tag-flag ) | |||
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | |||
x-key-t-tag-flag = hyphenated-word ; for future extension | x-key-t-tag-flag = hyphenated-word ; for future extension | |||
3.6.2. DNS Binding | 3.6.2. DNS Binding | |||
A binding using DNS TXT RRs as a key service is hereby defined. All | A binding using DNS TXT RRs as a key service is hereby defined. All | |||
implementations MUST support this binding. | implementations MUST support this binding. | |||
3.6.2.1. Namespace | 3.6.2.1. Namespace | |||
skipping to change at page 35, line 7 | skipping to change at page 33, line 42 | |||
With the exception of the canonicalization procedure described in | With the exception of the canonicalization procedure described in | |||
Section 3.4, the DKIM signing process treats the body of messages as | Section 3.4, the DKIM signing process treats the body of messages as | |||
simply a string of octets. DKIM messages MAY be either in plain-text | simply a string of octets. DKIM messages MAY be either in plain-text | |||
or in MIME format; no special treatment is afforded to MIME content. | or in MIME format; no special treatment is afforded to MIME content. | |||
Message attachments in MIME format MUST be included in the content | Message attachments in MIME format MUST be included in the content | |||
that is signed. | that is signed. | |||
More formally, pseudo-code for the signature algorithm is: | More formally, pseudo-code for the signature algorithm is: | |||
body-hash = hash-alg (canon-body, l-param) | body-hash = hash-alg (canon-body, l-param) | |||
data-hash = hash-alg (h-headers, D-SIG, content-hash) | data-hash = hash-alg (h-headers, D-SIG, body-hash) | |||
signature = sig-alg (d-domain, selector, data-hash) | signature = sig-alg (d-domain, selector, data-hash) | |||
where: | where: | |||
body-hash: is the output from hashing the body, using hash-alg. | body-hash: is the output from hashing the body, using hash-alg. | |||
hash-alg: is the hashing algorithm specified in the "a" | hash-alg: is the hashing algorithm specified in the "a" | |||
parameter. | parameter. | |||
canon-body: is a canonicalized representation of the body, | canon-body: is a canonicalized representation of the body, | |||
skipping to change at page 36, line 7 | skipping to change at page 34, line 46 | |||
selector: is the selector value specified in the "s" parameter. | selector: is the selector value specified in the "s" parameter. | |||
NOTE: Many digital signature APIs provide both hashing and | NOTE: Many digital signature APIs provide both hashing and | |||
application of the RSA private key using a single "sign()" | application of the RSA private key using a single "sign()" | |||
primitive. When using such an API, the last two steps in the | primitive. When using such an API, the last two steps in the | |||
algorithm would probably be combined into a single call that would | algorithm would probably be combined into a single call that would | |||
perform both the "a-hash-alg" and the "sig-alg". | perform both the "a-hash-alg" and the "sig-alg". | |||
3.8. Input Requirements | 3.8. Input Requirements | |||
DKIM's design is predicated on valid input. Therefore, signers and | A message that is not compliant with RFC5322, RFC2045 and RFC2047 can | |||
verifiers SHOULD take reasonable steps to ensure that the messages | be subject to attempts by intermediaries to correct or interpret such | |||
they are processing are valid according to [RFC5322], [RFC2045], and | content. See Section 8 of [RFC4409] for examples of changes that are | |||
any other relevant message format standards. See Section 8.14 and | commonly made. Such "corrections" may invalidate DKIM signatures or | |||
Section 8.15 for additional discussion and references. | have other undesirable effects, including some that involve changes | |||
to the way a message is presented to an end user. | ||||
Accordingly, DKIM's design is predicated on valid input. Therefore, | ||||
signers and verifiers SHOULD take reasonable steps to ensure that the | ||||
messages they are processing are valid according to [RFC5322], | ||||
[RFC2045], and any other relevant message format standards. | ||||
See Section 8.15 for additional discussion. | ||||
3.9. Output Requirements | 3.9. Output Requirements | |||
The evaluation of each signature ends in one of three states, which | ||||
this document refers to as follows: | ||||
SUCCESS: a successful verification | ||||
PERMFAIL: a permanent, non-recoverable error such as a signature | ||||
verification failure | ||||
TEMPFAIL: a temporary, recoverable error such as a DNS query timeout | ||||
For each signature that verifies successfully or produces a TEMPFAIL | For each signature that verifies successfully or produces a TEMPFAIL | |||
result, the output of a DKIM verifier module MUST include the set of: | result, output of the DKIM algorithm MUST include the set of: | |||
o The domain name, taken from the "d=" signature tag; and | o The domain name, taken from the "d=" signature tag; and | |||
o The result of the verification attempt for that signature. | o The result of the verification attempt for that signature. | |||
The output MAY include other signature properties or result meta- | The output MAY include other signature properties or result meta- | |||
data, including PERMFAILed or otherwise ignored signatures, for use | data, including PERMFAILed or otherwise ignored signatures, for use | |||
by modules that consume those results. | by modules that consume those results. | |||
See Section 6.1 for discussion of signature validation result codes. | See Section 6.1 for discussion of signature validation result codes. | |||
skipping to change at page 37, line 45 | skipping to change at page 37, line 10 | |||
be strictly limited. In particular, it is not at all clear to | be strictly limited. In particular, it is not at all clear to | |||
what extent a typical end-user recipient can rely on any | what extent a typical end-user recipient can rely on any | |||
assurances that might be made by successful use of the SDID or | assurances that might be made by successful use of the SDID or | |||
AUID. | AUID. | |||
4. Semantics of Multiple Signatures | 4. Semantics of Multiple Signatures | |||
4.1. Example Scenarios | 4.1. Example Scenarios | |||
There are many reasons why a message might have multiple signatures. | There are many reasons why a message might have multiple signatures. | |||
For example, a given signer might sign multiple times, perhaps with | For example, suppose SHA-256 is in the future found to be | |||
different hashing or signing algorithms during a transition phase. | insufficiently strong, and DKIM usage transitions to SHA-1024. A | |||
signer might immediately sign using the newer algorithm, but also | ||||
INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | continue to sign using the older algorithm for interoperability with | |||
insufficiently strong, and DKIM usage transitions to SHA-1024. A | verifiers that had not yet upgraded. The signer would do this by | |||
signer might immediately sign using the newer algorithm, but | adding two DKIM-Signature header fields, one using each algorithm. | |||
continue to sign using the older algorithm for interoperability | Older verifiers that did not recognize SHA-1024 as an acceptable | |||
with verifiers that had not yet upgraded. The signer would do | algorithm would skip that signature and use the older algorithm; | |||
this by adding two DKIM-Signature header fields, one using each | newer verifiers could use either signature at their option, and all | |||
algorithm. Older verifiers that did not recognize SHA-1024 as an | other things being equal might not even attempt to verify the other | |||
acceptable algorithm would skip that signature and use the older | signature. | |||
algorithm; newer verifiers could use either signature at their | ||||
option, and all other things being equal might not even attempt to | ||||
verify the other signature. | ||||
Similarly, a signer might sign a message including all headers and no | ||||
"l=" tag (to satisfy strict verifiers) and a second time with a | ||||
limited set of headers and an "l=" tag (in anticipation of possible | ||||
message modifications in route to other verifiers). Verifiers could | ||||
then choose which signature they preferred. | ||||
INFORMATIVE EXAMPLE: A verifier might receive a message with two | Similarly, a signer might sign a message including all header fields | |||
signatures, one covering more of the message than the other. If | and no "l=" tag (to satisfy strict verifiers) and a second time with | |||
the signature covering more of the message verified, then the | a limited set of header fields and an "l=" tag (in anticipation of | |||
verifier could make one set of policy decisions; if that signature | possible message modifications en route to other verifiers). | |||
failed but the signature covering less of the message verified, | Verifiers could then choose which signature they preferred. | |||
the verifier might make a different set of policy decisions. | ||||
Of course, a message might also have multiple signatures because it | Of course, a message might also have multiple signatures because it | |||
passed through multiple signers. A common case is expected to be | passed through multiple signers. A common case is expected to be | |||
that of a signed message that passes through a mailing list that also | that of a signed message that passes through a mailing list that also | |||
signs all messages. Assuming both of those signatures verify, a | signs all messages. Assuming both of those signatures verify, a | |||
recipient might choose to accept the message if either of those | recipient might choose to accept the message if either of those | |||
signatures were known to come from trusted sources. | signatures were known to come from trusted sources. | |||
INFORMATIVE EXAMPLE: Recipients might choose to whitelist mailing | In particular, recipients might choose to whitelist mailing lists to | |||
lists to which they have subscribed and that have acceptable anti- | which they have subscribed and that have acceptable anti-abuse | |||
abuse policies so as to accept messages sent to that list even | policies so as to accept messages sent to that list even from unknown | |||
from unknown authors. They might also subscribe to less trusted | authors. They might also subscribe to less trusted mailing lists | |||
mailing lists (e.g., those without anti-abuse protection) and be | (e.g., those without anti-abuse protection) and be willing to accept | |||
willing to accept all messages from specific authors, but insist | all messages from specific authors, but insist on doing additional | |||
on doing additional abuse scanning for other messages. | abuse scanning for other messages. | |||
Another related example of multiple signers might be forwarding | Another related example of multiple signers might be forwarding | |||
services, such as those commonly associated with academic alumni | services, such as those commonly associated with academic alumni | |||
sites. | sites. For example, a recipient might have an address at | |||
members.example.org, a site that has anti-abuse protection that is | ||||
INFORMATIVE EXAMPLE: A recipient might have an address at | somewhat less effective than the recipient would prefer. Such a | |||
members.example.org, a site that has anti-abuse protection that is | recipient might have specific authors whose messages would be trusted | |||
somewhat less effective than the recipient would prefer. Such a | absolutely, but messages from unknown authors that had passed the | |||
recipient might have specific authors whose messages would be | forwarder's scrutiny would have only medium trust. | |||
trusted absolutely, but messages from unknown authors that had | ||||
passed the forwarder's scrutiny would have only medium trust. | ||||
4.2. Interpretation | 4.2. Interpretation | |||
A signer that is adding a signature to a message merely creates a new | A signer that is adding a signature to a message merely creates a new | |||
DKIM-Signature header, using the usual semantics of the h= option. A | DKIM-Signature header, using the usual semantics of the h= option. A | |||
signer MAY sign previously existing DKIM-Signature header fields | signer MAY sign previously existing DKIM-Signature header fields | |||
using the method described in Section 5.4 to sign trace header | using the method described in Section 5.4 to sign trace header | |||
fields. | fields. | |||
INFORMATIVE NOTE: Signers should be cognizant that signing DKIM- | Note that signers should be cognizant that signing DKIM-Signature | |||
Signature header fields may result in signature failures with | header fields may result in signature failures with intermediaries | |||
intermediaries that do not recognize that DKIM-Signature header | that do not recognize that DKIM-Signature header fields are trace | |||
fields are trace header fields and unwittingly reorder them, thus | header fields and unwittingly reorder them, thus breaking such | |||
breaking such signatures. For this reason, signing existing DKIM- | signatures. For this reason, signing existing DKIM-Signature header | |||
Signature header fields is unadvised, albeit legal. | fields is unadvised, albeit legal. | |||
INFORMATIVE NOTE: If a header field with multiple instances is | INFORMATIVE NOTE: If a header field with multiple instances is | |||
signed, those header fields are always signed from the bottom up. | signed, those header fields are always signed from the bottom up. | |||
Thus, it is not possible to sign only specific DKIM-Signature | Thus, it is not possible to sign only specific DKIM-Signature | |||
header fields. For example, if the message being signed already | header fields. For example, if the message being signed already | |||
contains three DKIM-Signature header fields A, B, and C, it is | contains three DKIM-Signature header fields A, B, and C, it is | |||
possible to sign all of them, B and C only, or C only, but not A | possible to sign all of them, B and C only, or C only, but not A | |||
only, B only, A and B only, or A and C only. | only, B only, A and B only, or A and C only. | |||
A signer MAY add more than one DKIM-Signature header field using | A signer MAY add more than one DKIM-Signature header field using | |||
skipping to change at page 40, line 27 | skipping to change at page 39, line 27 | |||
The following steps are performed in order by signers. | The following steps are performed in order by signers. | |||
5.1. Determine Whether the Email Should Be Signed and by Whom | 5.1. Determine Whether the Email Should Be Signed and by Whom | |||
A signer can obviously only sign email for domains for which it has a | A signer can obviously only sign email for domains for which it has a | |||
private key and the necessary knowledge of the corresponding public | private key and the necessary knowledge of the corresponding public | |||
key and selector information. However, there are a number of other | key and selector information. However, there are a number of other | |||
reasons beyond the lack of a private key why a signer could choose | reasons beyond the lack of a private key why a signer could choose | |||
not to sign an email. | not to sign an email. | |||
INFORMATIVE NOTE: Signing modules may be incorporated into any | INFORMATIVE NOTE: A signer can be implemented as part of any | |||
portion of the mail system as deemed appropriate, including an | portion of the mail system as deemed appropriate, including an | |||
MUA, a SUBMISSION server, or an MTA. Wherever implemented, | MUA, a SUBMISSION server, or an MTA. Wherever implemented, | |||
signers should beware of signing (and thereby asserting | signers should beware of signing (and thereby asserting | |||
responsibility for) messages that may be problematic. In | responsibility for) messages that may be problematic. In | |||
particular, within a trusted enclave the signing address might be | particular, within a trusted enclave the signing domain might be | |||
derived from the header according to local policy; SUBMISSION | derived from the header according to local policy; SUBMISSION | |||
servers might only sign messages from users that are properly | servers might only sign messages from users that are properly | |||
authenticated and authorized. | authenticated and authorized. | |||
INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign | INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign | |||
Received header fields if the outgoing gateway MTA obfuscates | Received header fields if the outgoing gateway MTA obfuscates | |||
Received header fields, for example, to hide the details of | Received header fields, for example, to hide the details of | |||
internal topology. | internal topology. | |||
If an email cannot be signed for some reason, it is a local policy | If an email cannot be signed for some reason, it is a local policy | |||
skipping to change at page 41, line 10 | skipping to change at page 40, line 10 | |||
choose which private key and selector information to use. Currently, | choose which private key and selector information to use. Currently, | |||
all selectors are equal as far as this specification is concerned, so | all selectors are equal as far as this specification is concerned, so | |||
the decision should largely be a matter of administrative | the decision should largely be a matter of administrative | |||
convenience. Distribution and management of private keys is also | convenience. Distribution and management of private keys is also | |||
outside the scope of this document. | outside the scope of this document. | |||
INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | |||
private key when the selector containing the corresponding public | private key when the selector containing the corresponding public | |||
key is expected to be revoked or removed before the verifier has | key is expected to be revoked or removed before the verifier has | |||
an opportunity to validate the signature. The signer should | an opportunity to validate the signature. The signer should | |||
anticipate that verifiers may choose to defer validation, perhaps | anticipate that verifiers can choose to defer validation, perhaps | |||
until the message is actually read by the final recipient. In | until the message is actually read by the final recipient. In | |||
particular, when rotating to a new key pair, signing should | particular, when rotating to a new key pair, signing should | |||
immediately commence with the new private key and the old public | immediately commence with the new private key and the old public | |||
key should be retained for a reasonable validation interval before | key should be retained for a reasonable validation interval before | |||
being removed from the key server. | being removed from the key server. | |||
5.3. Normalize the Message to Prevent Transport Conversions | 5.3. Normalize the Message to Prevent Transport Conversions | |||
Some messages, particularly those using 8-bit characters, are subject | Some messages, particularly those using 8-bit characters, are subject | |||
to modification during transit, notably conversion to 7-bit form. | to modification during transit, notably conversion to 7-bit form. | |||
Such conversions will break DKIM signatures. In order to minimize | Such conversions will break DKIM signatures. In order to minimize | |||
the chances of such breakage, signers SHOULD convert the message to a | the chances of such breakage, signers SHOULD convert the message to a | |||
suitable MIME content transfer encoding such as quoted-printable or | suitable MIME content transfer encoding such as quoted-printable or | |||
base64 as described in [RFC2045] before signing. Such conversion is | base64 as described in [RFC2045] before signing. Such conversion is | |||
outside the scope of DKIM; the actual message SHOULD be converted to | outside the scope of DKIM; the actual message SHOULD be converted to | |||
7-bit MIME by an MUA or MSA prior to presentation to the DKIM | 7-bit MIME by an MUA or MSA prior to presentation to the DKIM | |||
algorithm. | algorithm. | |||
Similarly, a message that is not compliant with RFC5322, RFC2045 and | ||||
RFC2047 can be subject to attempts by intermediaries to correct or | ||||
interpret such content. See Section 8 of [RFC4409] for examples of | ||||
changes that are commonly made. Such "corrections" may break DKIM | ||||
signatures or have other undesirable effects. Therefore, a verifier | ||||
SHOULD NOT validate a message that is not compliant with those | ||||
specifications. | ||||
If the message is submitted to the signer with any local encoding | If the message is submitted to the signer with any local encoding | |||
that will be modified before transmission, that modification to | that will be modified before transmission, that modification to | |||
canonical [RFC5322] form MUST be done before signing. In particular, | canonical [RFC5322] form MUST be done before signing. In particular, | |||
bare CR or LF characters (used by some systems as a local line | bare CR or LF characters (used by some systems as a local line | |||
separator convention) MUST be converted to the SMTP-standard CRLF | separator convention) MUST be converted to the SMTP-standard CRLF | |||
sequence before the message is signed. Any conversion of this sort | sequence before the message is signed. Any conversion of this sort | |||
SHOULD be applied to the message actually sent to the recipient(s), | SHOULD be applied to the message actually sent to the recipient(s), | |||
not just to the version presented to the signing algorithm. | not just to the version presented to the signing algorithm. | |||
More generally, the signer MUST sign the message as it is expected to | More generally, the signer MUST sign the message as it is expected to | |||
be received by the verifier rather than in some local or internal | be received by the verifier rather than in some local or internal | |||
form. | form. | |||
5.3.1. Body Length Limits | ||||
A body length count MAY be specified to limit the signature | ||||
calculation to an initial prefix of the body text, measured in | ||||
octets. If the body length count is not specified, the entire | ||||
message body is signed. | ||||
INFORMATIVE RATIONALE: This capability is provided because it is | ||||
very common for mailing lists to add trailers to messages (e.g., | ||||
instructions how to get off the list). Until those messages are | ||||
also signed, the body length count is a useful tool for the | ||||
verifier since it may as a matter of policy accept messages having | ||||
valid signatures with extraneous data. | ||||
The length actually hashed should be inserted in the "l=" tag of the | ||||
DKIM-Signature header field. (See Section 3.5.) | ||||
The body length count allows the signer of a message to permit data | ||||
to be appended to the end of the body of a signed message. The body | ||||
length count MUST be calculated following the canonicalization | ||||
algorithm; for example, any whitespace ignored by a canonicalization | ||||
algorithm is not included as part of the body length count. | ||||
A body length count of zero means that the body is completely | ||||
unsigned. | ||||
Signers wishing to ensure that no modification of any sort can occur | ||||
should specify the "simple" canonicalization algorithm for both | ||||
header and body and omit the body length count. | ||||
See Section 8.2 for further discussion. | ||||
5.4. Determine the Header Fields to Sign | 5.4. Determine the Header Fields to Sign | |||
The From header field MUST be signed (that is, included in the "h=" | The From header field MUST be signed (that is, included in the "h=" | |||
tag of the resulting DKIM-Signature header field). Signers SHOULD | tag of the resulting DKIM-Signature header field). Signers SHOULD | |||
NOT sign an existing header field likely to be legitimately modified | NOT sign an existing header field likely to be legitimately modified | |||
or removed in transit. In particular, [RFC5321] explicitly permits | or removed in transit. In particular, [RFC5321] explicitly permits | |||
modification or removal of the Return-Path header field in transit. | modification or removal of the Return-Path header field in transit. | |||
Signers MAY include any other header fields present at the time of | Signers MAY include any other header fields present at the time of | |||
signing at the discretion of the signer. | signing at the discretion of the signer. | |||
skipping to change at page 42, line 52 | skipping to change at page 42, line 25 | |||
INFORMATIVE NOTE: A header field name need only be listed once | INFORMATIVE NOTE: A header field name need only be listed once | |||
more than the actual number of that header field in a message at | more than the actual number of that header field in a message at | |||
the time of signing in order to prevent any further additions. | the time of signing in order to prevent any further additions. | |||
For example, if there is a single Comments header field at the | For example, if there is a single Comments header field at the | |||
time of signing, listing Comments twice in the "h=" tag is | time of signing, listing Comments twice in the "h=" tag is | |||
sufficient to prevent any number of Comments header fields from | sufficient to prevent any number of Comments header fields from | |||
being appended; it is not necessary (but is legal) to list | being appended; it is not necessary (but is legal) to list | |||
Comments three or more times in the "h=" tag. | Comments three or more times in the "h=" tag. | |||
Signers choosing to sign an existing header field that occurs more | Refer to Section 5.4.2 for a discussion of the procedure to be | |||
than once in the message (such as Received) MUST sign the physically | followed when canonicalizing a header with more than one instance of | |||
last instance of that header field in the header block. Signers | a particular header field name. | |||
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. | ||||
INFORMATIVE EXAMPLE: | ||||
If the signer wishes to sign two existing Received header fields, | ||||
and the existing header contains: | ||||
Received: <A> | ||||
Received: <B> | ||||
Received: <C> | ||||
then the resulting DKIM-Signature header field should read: | ||||
DKIM-Signature: ... h=Received : Received :... | ||||
and Received header fields <C> and <B> will be signed in that | ||||
order. | ||||
Signers should be careful of signing header fields that might have | Signers need to be careful of signing header fields that might have | |||
additional instances added later in the delivery process, since such | additional instances added later in the delivery process, since such | |||
header fields might be inserted after the signed instance or | header fields might be inserted after the signed instance or | |||
otherwise reordered. Trace header fields (such as Received) and | otherwise reordered. Trace header fields (such as Received) and | |||
Resent-* blocks are the only fields prohibited by [RFC5322] from | Resent-* blocks are the only fields prohibited by [RFC5322] from | |||
being reordered. In particular, since DKIM-Signature header fields | being reordered. In particular, since DKIM-Signature header fields | |||
may be reordered by some intermediate MTAs, signing existing DKIM- | may be reordered by some intermediate MTAs, signing existing DKIM- | |||
Signature header fields is error-prone. | Signature header fields is error-prone. | |||
INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits | INFORMATIVE ADMONITION: Despite the fact that [RFC5322] does not | |||
header fields to be reordered (with the exception of Received | prohibit the reordering of header fields, reordering of signed | |||
header fields), reordering of signed header fields with multiple | header fields with multiple instances by intermediate MTAs will | |||
instances by intermediate MTAs will cause DKIM signatures to be | cause DKIM signatures to be broken; such anti-social behavior | |||
broken; such anti-social behavior should be avoided. | should be avoided. | |||
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | |||
specification, all end-user visible header fields should be signed | specification, all end-user visible header fields should be signed | |||
to avoid possible "indirect spamming". For example, if the | to avoid possible "indirect spamming". For example, if the | |||
Subject header field is not signed, a spammer can resend a | Subject header field is not signed, a spammer can resend a | |||
previously signed mail, replacing the legitimate subject with a | previously signed mail, replacing the legitimate subject with a | |||
one-line spam. | one-line spam. | |||
5.5. Recommended Signature Content | 5.4.1. Recommended Signature Content | |||
The purpose of the DKIM cryptographic algorithm is to affix an | The purpose of the DKIM cryptographic algorithm is to affix an | |||
identifier to the message in a way that is both robust against normal | identifier to the message in a way that is both robust against normal | |||
transit-related changes and resistant to kinds of replay attacks. An | transit-related changes and resistant to kinds of replay attacks. An | |||
essential aspect of satisfying these requirements is choosing what | essential aspect of satisfying these requirements is choosing what | |||
header fields to include in the hash and what fields to exclude. | header fields to include in the hash and what fields to exclude. | |||
The basic rule for choosing fields to include is to select those | The basic rule for choosing fields to include is to select those | |||
fields that constitute the "core" of the message content. Hence, any | fields that constitute the "core" of the message content. Hence, any | |||
replay attack will have to include these in order to have the | replay attack will have to include these in order to have the | |||
skipping to change at page 45, line 37 | skipping to change at page 44, line 37 | |||
Signers SHOULD choose canonicalization algorithms based on the types | Signers SHOULD choose canonicalization algorithms based on the types | |||
of messages they process and their aversion to risk. For example, | of messages they process and their aversion to risk. For example, | |||
e-commerce sites sending primarily purchase receipts, which are not | e-commerce sites sending primarily purchase receipts, which are not | |||
expected to be processed by mailing lists or other software likely to | expected to be processed by mailing lists or other software likely to | |||
modify messages, will generally prefer "simple" canonicalization. | modify messages, will generally prefer "simple" canonicalization. | |||
Sites sending primarily person-to-person email will likely prefer to | Sites sending primarily person-to-person email will likely prefer to | |||
be more resilient to modification during transport by using "relaxed" | be more resilient to modification during transport by using "relaxed" | |||
canonicalization. | canonicalization. | |||
Signers SHOULD NOT use "l=" unless they intend to accommodate | Unless mail is processed through intermediaries, such as mailing | |||
intermediate mail processors that append text to a message. For | lists that might add "unsubscribe" instructions to the bottom of the | |||
example, many mailing list processors append "unsubscribe" | message body, the "l=" tag is likely to convey no additional benefit | |||
information to message bodies. If signers use "l=", they SHOULD | while providing an avenue for unauthorized addition of text to a | |||
include the entire message body existing at the time of signing in | message. The use of "l=0" takes this to the extreme, allowing | |||
computing the count. In particular, signers SHOULD NOT specify a | complete alteration of the text of the message without invalidating | |||
body length of 0 since this may be interpreted as a meaningless | the signature. Moreover, a verifier would be within its rights to | |||
signature by some verifiers. | consider a partly-signed message body as unacceptable. Judicious use | |||
is advised. | ||||
5.6. Compute the Message Hash and Signature | 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. | ||||
INFORMATIVE EXAMPLE: | ||||
If the signer wishes to sign two existing Received header fields, | ||||
and the existing header contains: | ||||
Received: <A> | ||||
Received: <B> | ||||
Received: <C> | ||||
then the resulting DKIM-Signature header field should read: | ||||
DKIM-Signature: ... h=Received : Received :... | ||||
and Received header fields <C> and <B> will be signed in that | ||||
order. | ||||
5.5. Compute the Message Hash and Signature | ||||
The signer MUST compute the message hash as described in Section 3.7 | The signer MUST compute the message hash as described in Section 3.7 | |||
and then sign it using the selected public-key algorithm. This will | and then sign it using the selected public-key algorithm. This will | |||
result in a DKIM-Signature header field that will include the body | result in a DKIM-Signature header field that will include the body | |||
hash and a signature of the header hash, where that header includes | hash and a signature of the header hash, where that header includes | |||
the DKIM-Signature header field itself. | the DKIM-Signature header field itself. | |||
Entities such as mailing list managers that implement DKIM and that | Entities such as mailing list managers that implement DKIM and that | |||
modify the message or a header field (for example, inserting | modify the message or a header field (for example, inserting | |||
unsubscribe information) before retransmitting the message SHOULD | unsubscribe information) before retransmitting the message SHOULD | |||
check any existing signature on input and MUST make such | check any existing signature on input and MUST make such | |||
modifications before re-signing the message. | modifications before re-signing the message. | |||
The signer MAY elect to limit the number of bytes of the body that | 5.6. Insert the DKIM-Signature Header Field | |||
will be included in the hash and hence signed. The length actually | ||||
hashed should be inserted in the "l=" tag of the DKIM-Signature | ||||
header field. | ||||
5.7. Insert the DKIM-Signature Header Field | ||||
Finally, the signer MUST insert the DKIM-Signature header field | Finally, the signer MUST insert the DKIM-Signature header field | |||
created in the previous step prior to transmitting the email. The | created in the previous step prior to transmitting the email. The | |||
DKIM-Signature header field MUST be the same as used to compute the | DKIM-Signature header field MUST be the same as used to compute the | |||
hash as described above, except that the value of the "b=" tag MUST | hash as described above, except that the value of the "b=" tag MUST | |||
be the appropriately signed hash computed in the previous step, | be the appropriately signed hash computed in the previous step, | |||
signed using the algorithm specified in the "a=" tag of the DKIM- | signed using the algorithm specified in the "a=" tag of the DKIM- | |||
Signature header field and using the private key corresponding to the | Signature header field and using the private key corresponding to the | |||
selector given in the "s=" tag of the DKIM-Signature header field, as | selector given in the "s=" tag of the DKIM-Signature header field, as | |||
chosen above in Section 5.2 | chosen above in Section 5.2 | |||
skipping to change at page 47, line 36 | skipping to change at page 47, line 11 | |||
multiple DKIM-Signature header fields. In particular, there is | multiple DKIM-Signature header fields. In particular, there is | |||
reason to believe that some relays will reorder the header fields in | reason to believe that some relays will reorder the header fields in | |||
potentially arbitrary ways. | potentially arbitrary ways. | |||
INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as | INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as | |||
a clue to signing order in the absence of any other information. | a clue to signing order in the absence of any other information. | |||
However, other clues as to the semantics of multiple signatures | However, other clues as to the semantics of multiple signatures | |||
(such as correlating the signing host with Received header fields) | (such as correlating the signing host with Received header fields) | |||
might also be considered. | might also be considered. | |||
A verifier SHOULD NOT treat a message that has one or more bad | Survivability of signatures after transit is not guaranteed, and | |||
signatures and no good signatures differently from a message with no | signatures can fail to verify through no fault of the signer. | |||
signature at all; such treatment is a matter of local policy and is | Therefore, a verifier SHOULD NOT treat a message that has one or more | |||
beyond the scope of this document. | bad signatures and no good signatures differently from a message with | |||
no signature at all. | ||||
When a signature successfully verifies, a verifier will either stop | When a signature successfully verifies, a verifier will either stop | |||
processing or attempt to verify any other signatures, at the | processing or attempt to verify any other signatures, at the | |||
discretion of the implementation. A verifier MAY limit the number of | discretion of the implementation. A verifier MAY limit the number of | |||
signatures it tries to avoid denial-of-service attacks. | signatures it tries, in order to avoid denial-of-service attacks (see | |||
Section 8.4 for further discussion). | ||||
INFORMATIVE NOTE: An attacker could send messages with large | ||||
numbers of faulty signatures, each of which would require a DNS | ||||
lookup and corresponding CPU time to verify the message. This | ||||
could be an attack on the domain that receives the message, by | ||||
slowing down the verifier by requiring it to do a large number of | ||||
DNS lookups and/or signature verifications. It could also be an | ||||
attack against the domains listed in the signatures, essentially | ||||
by enlisting innocent verifiers in launching an attack against the | ||||
DNS servers of the actual victim. | ||||
In the following description, text reading "return status | In the following description, text reading "return status | |||
(explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") | (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") | |||
means that the verifier MUST immediately cease processing that | means that the verifier MUST immediately cease processing that | |||
signature. The verifier SHOULD proceed to the next signature, if any | signature. The verifier SHOULD proceed to the next signature, if any | |||
is present, and completely ignore the bad signature. If the status | is present, and completely ignore the bad signature. If the status | |||
is "PERMFAIL", the signature failed and should not be reconsidered. | is "PERMFAIL", the signature failed and should not be reconsidered. | |||
If the status is "TEMPFAIL", the signature could not be verified at | If the status is "TEMPFAIL", the signature could not be verified at | |||
this time but may be tried again later. A verifier MAY either | this time but may be tried again later. A verifier MAY either | |||
arrange to defer the message for later processing, or try another | arrange to defer the message for later processing, or try another | |||
skipping to change at page 49, line 39 | skipping to change at page 49, line 5 | |||
MUST ignore the DKIM-Signature header field and return PERMFAIL (From | MUST ignore the DKIM-Signature header field and return PERMFAIL (From | |||
field not signed). | field not signed). | |||
Verifiers MAY ignore the DKIM-Signature header field and return | Verifiers MAY ignore the DKIM-Signature header field and return | |||
PERMFAIL (signature expired) if it contains an "x=" tag and the | PERMFAIL (signature expired) if it contains an "x=" tag and the | |||
signature has expired. | signature has expired. | |||
Verifiers MAY ignore the DKIM-Signature header field if the domain | Verifiers MAY ignore the DKIM-Signature header field if the domain | |||
used by the signer in the "d=" tag is not associated with a valid | used by the signer in the "d=" tag is not associated with a valid | |||
signing entity. For example, signatures with "d=" values such as | signing entity. For example, signatures with "d=" values such as | |||
"com" and "co.uk" may be ignored. The list of unacceptable domains | "com" and "co.uk" could be ignored. The list of unacceptable domains | |||
SHOULD be configurable. | SHOULD be configurable. | |||
Verifiers MAY ignore the DKIM-Signature header field and return | Verifiers MAY ignore the DKIM-Signature header field and return | |||
PERMFAIL (unacceptable signature header) for any other reason, for | PERMFAIL (unacceptable signature header) for any other reason, for | |||
example, if the signature does not sign header fields that the | example, if the signature does not sign header fields that the | |||
verifier views to be essential. As a case in point, if MIME header | verifier views to be essential. As a case in point, if MIME header | |||
fields are not signed, certain attacks may be possible that the | fields are not signed, certain attacks may be possible that the | |||
verifier would prefer to avoid. | verifier would prefer to avoid. | |||
6.1.2. Get the Public Key | 6.1.2. Get the Public Key | |||
skipping to change at page 50, line 36 | skipping to change at page 49, line 51 | |||
2. If the query for the public key fails to respond, the verifier | 2. If the query for the public key fails to respond, the verifier | |||
MAY seek a later verification attempt by returning TEMPFAIL (key | MAY seek a later verification attempt by returning TEMPFAIL (key | |||
unavailable). | unavailable). | |||
3. If the query for the public key fails because the corresponding | 3. If the query for the public key fails because the corresponding | |||
key record does not exist, the verifier MUST immediately return | key record does not exist, the verifier MUST immediately return | |||
PERMFAIL (no key for signature). | PERMFAIL (no key for signature). | |||
4. If the query for the public key returns multiple key records, the | 4. If the query for the public key returns multiple key records, the | |||
verifier may choose one of the key records or may cycle through | verifier can choose one of the key records or may cycle through | |||
the key records performing the remainder of these steps on each | the key records performing the remainder of these steps on each | |||
record at the discretion of the implementer. The order of the | record at the discretion of the implementer. The order of the | |||
key records is unspecified. If the verifier chooses to cycle | key records is unspecified. If the verifier chooses to cycle | |||
through the key records, then the "return ..." wording in the | through the key records, then the "return ..." wording in the | |||
remainder of this section means "try the next key record, if any; | remainder of this section means "try the next key record, if any; | |||
if none, return to try another signature in the usual way". | if none, return to try another signature in the usual way". | |||
5. If the result returned from the query does not adhere to the | 5. If the result returned from the query does not adhere to the | |||
format defined in this specification, the verifier MUST ignore | format defined in this specification, the verifier MUST ignore | |||
the key record and return PERMFAIL (key syntax error). Verifiers | the key record and return PERMFAIL (key syntax error). Verifiers | |||
skipping to change at page 51, line 30 | skipping to change at page 50, line 43 | |||
PERMFAIL (inappropriate key algorithm). | PERMFAIL (inappropriate key algorithm). | |||
6.1.3. Compute the Verification | 6.1.3. Compute the Verification | |||
Given a signer and a public key, verifying a signature consists of | Given a signer and a public key, verifying a signature consists of | |||
actions semantically equivalent to the following steps. | actions semantically equivalent to the following steps. | |||
1. Based on the algorithm defined in the "c=" tag, the body length | 1. Based on the algorithm defined in the "c=" tag, the body length | |||
specified in the "l=" tag, and the header field names in the "h=" | specified in the "l=" tag, and the header field names in the "h=" | |||
tag, prepare a canonicalized version of the message as is | tag, prepare a canonicalized version of the message as is | |||
described in Section 3.7 (note that this version does not | described in Section 3.7 (note that this canonicalized version | |||
actually need to be instantiated). When matching header field | does not actually replace the original content). When matching | |||
names in the "h=" tag against the actual message header field, | header field names in the "h=" tag against the actual message | |||
comparisons MUST be case-insensitive. | header field, comparisons MUST be case-insensitive. | |||
2. Based on the algorithm indicated in the "a=" tag, compute the | 2. Based on the algorithm indicated in the "a=" tag, compute the | |||
message hashes from the canonical copy as described in | message hashes from the canonical copy as described in | |||
Section 3.7. | Section 3.7. | |||
3. Verify that the hash of the canonicalized message body computed | 3. Verify that the hash of the canonicalized message body computed | |||
in the previous step matches the hash value conveyed in the "bh=" | in the previous step matches the hash value conveyed in the "bh=" | |||
tag. If the hash does not match, the verifier SHOULD ignore the | tag. If the hash does not match, the verifier SHOULD ignore the | |||
signature and return PERMFAIL (body hash did not verify). | signature and return PERMFAIL (body hash did not verify). | |||
skipping to change at page 52, line 18 | skipping to change at page 51, line 31 | |||
calculated. Implementations may also verify the signature on the | calculated. Implementations may also verify the signature on the | |||
message header before validating that the message hash listed in | message header before validating that the message hash listed in | |||
the "bh=" tag in the DKIM-Signature header field matches that of | the "bh=" tag in the DKIM-Signature header field matches that of | |||
the actual message body; however, if the body hash does not match, | the actual message body; however, if the body hash does not match, | |||
the entire signature must be considered to have failed. | the entire signature must be considered to have failed. | |||
A body length specified in the "l=" tag of the signature limits the | A body length specified in the "l=" tag of the signature limits the | |||
number of bytes of the body passed to the verification algorithm. | number of bytes of the body passed to the verification algorithm. | |||
All data beyond that limit is not validated by DKIM. Hence, | All data beyond that limit is not validated by DKIM. Hence, | |||
verifiers might treat a message that contains bytes beyond the | verifiers might treat a message that contains bytes beyond the | |||
indicated body length with suspicion, such as by declaring the | indicated body length with suspicion, and can choose to treat the | |||
signature invalid (e.g., by returning PERMFAIL (unsigned content)), | signature as if it were invalid (e.g., by returning PERMFAIL | |||
or conveying the partial verification to the policy module. | (unsigned content)). | |||
Should the algorithm reach this point, the verification has | ||||
succeeded, and DKIM reports SUCCESS for this signature. | ||||
6.2. Communicate Verification Results | 6.2. Communicate Verification Results | |||
Verifiers wishing to communicate the results of verification to other | Verifiers wishing to communicate the results of verification to other | |||
parts of the mail system may do so in whatever manner they see fit. | parts of the mail system may do so in whatever manner they see fit. | |||
For example, implementations might choose to add an email header | For example, implementations might choose to add an email header | |||
field to the message before passing it on. Any such header field | field to the message before passing it on. Any such header field | |||
SHOULD be inserted before any existing DKIM-Signature or preexisting | SHOULD be inserted before any existing DKIM-Signature or preexisting | |||
authentication status header fields in the header field block. The | authentication status header fields in the header field block. The | |||
Authentication-Results: header field ([RFC5451]) MAY be used for this | Authentication-Results: header field ([RFC5451]) MAY be used for this | |||
skipping to change at page 53, line 46 | skipping to change at page 53, line 14 | |||
difficult. If a selector cannot be found, is that because the | difficult. If a selector cannot be found, is that because the | |||
selector has been removed, or was the value changed somehow in | selector has been removed, or was the value changed somehow in | |||
transit? If the signature line is missing, is that because it was | transit? If the signature line is missing, is that because it was | |||
never there, or was it removed by an overzealous filter? For | never there, or was it removed by an overzealous filter? For | |||
diagnostic purposes, the exact reason why the verification fails | diagnostic purposes, the exact reason why the verification fails | |||
SHOULD be made available and possibly recorded in the system logs. | SHOULD be made available and possibly recorded in the system logs. | |||
If the email cannot be verified, then it SHOULD be treated the same | If the email cannot be verified, then it SHOULD be treated the same | |||
as all unverified email regardless of whether or not it looks like it | as all unverified email regardless of whether or not it looks like it | |||
was signed. | was signed. | |||
See Section 8.14 and Section 8.15 for additional discussion and | See Section 8.15 for additional discussion. | |||
references. | ||||
7. IANA Considerations | 7. IANA Considerations | |||
DKIM has registered namespaces with IANA. In all cases, new values | DKIM has registered namespaces with IANA. In all cases, new values | |||
are assigned only for values that have been documented in a published | are assigned only for values that have been documented in a published | |||
RFC that has IETF Consensus [RFC5226]. | RFC that has IETF Consensus [RFC5226]. | |||
This memo updates these registries as described below. Of note is | This memo updates these registries as described below. Of note is | |||
the addition of a new "status" column. All registrations into these | the addition of a new "status" column. All registrations into these | |||
namespaces MUST include the name being registered, the document in | namespaces MUST include the name being registered, the document in | |||
which it was registered or updated, and an indication of its current | which it was registered or updated, and an indication of its current | |||
status which MUST be one of "active" (in current use) or "historic" | status which MUST be one of "active" (in current use) or "historic" | |||
(no longer in current use). | (no longer in current use). | |||
No new tags are defined in this specification compared to [RFC4871], | No new tags are defined in this specification compared to [RFC4871], | |||
but one has been obsoleted. | but one has been designated as "historic". | |||
7.1. DKIM-Signature Tag Specifications | Also, the Email Authentication Methods Registry is revised to refer | |||
to this update. | ||||
7.1. Email Authentication Methods Registry | ||||
The Email Authentication Methods registry is updated to indicate that | ||||
"dkim" is defined in this memo. | ||||
7.2. DKIM-Signature Tag Specifications | ||||
A DKIM-Signature provides for a list of tag specifications. IANA has | A DKIM-Signature provides for a list of tag specifications. IANA has | |||
established the DKIM-Signature Tag Specification Registry for tag | established the DKIM-Signature Tag Specification Registry for tag | |||
specifications that can be used in DKIM-Signature fields. | specifications that can be used in DKIM-Signature fields. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
skipping to change at page 55, line 5 | skipping to change at page 54, line 26 | |||
| l | (this document) | active | | | l | (this document) | active | | |||
| q | (this document) | active | | | q | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
| t | (this document) | active | | | t | (this document) | active | | |||
| x | (this document) | active | | | x | (this document) | active | | |||
| z | (this document) | active | | | z | (this document) | active | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
Table 1: DKIM-Signature Tag Specification Registry Updated Values | Table 1: DKIM-Signature Tag Specification Registry Updated Values | |||
7.2. DKIM-Signature Query Method Registry | 7.3. DKIM-Signature Query Method Registry | |||
The "q=" tag-spec (specified in Section 3.5) provides for a list of | The "q=" tag-spec (specified in Section 3.5) provides for a list of | |||
query methods. | query methods. | |||
IANA has established the DKIM-Signature Query Method Registry for | IANA has established the DKIM-Signature Query Method Registry for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM. | validation processing of a message signed using DKIM. | |||
The updated entry in the registry comprises: | The updated entry in the registry comprises: | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
| TYPE | OPTION | REFERENCE | STATUS | | | TYPE | OPTION | REFERENCE | STATUS | | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
| dns | txt | (this document) | active | | | dns | txt | (this document) | active | | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
DKIM-Signature Query Method Registry Updated Values | DKIM-Signature Query Method Registry Updated Values | |||
7.3. DKIM-Signature Canonicalization Registry | 7.4. DKIM-Signature Canonicalization Registry | |||
The "c=" tag-spec (specified in Section 3.5) provides for a specifier | The "c=" tag-spec (specified in Section 3.5) provides for a specifier | |||
for canonicalization algorithms for the header and body of the | for canonicalization algorithms for the header and body of the | |||
message. | message. | |||
IANA has established the DKIM-Signature Canonicalization Algorithm | IANA has established the DKIM-Signature Canonicalization Algorithm | |||
Registry for algorithms for converting a message into a canonical | Registry for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM. | form before signing or verifying using DKIM. | |||
The updated entries in the header registry comprise: | The updated entries in the header registry comprise: | |||
skipping to change at page 56, line 10 | skipping to change at page 55, line 30 | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| simple | (this document) | active | | | simple | (this document) | active | | |||
| relaxed | (this document) | active | | | relaxed | (this document) | active | | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
DKIM-Signature Body Canonicalization Algorithm Registry | DKIM-Signature Body Canonicalization Algorithm Registry | |||
Updated Values | Updated Values | |||
7.4. _domainkey DNS TXT Resource Record Tag Specifications | 7.5. _domainkey DNS TXT Resource Record Tag Specifications | |||
A _domainkey DNS TXT RR provides for a list of tag specifications. | A _domainkey DNS TXT RR provides for a list of tag specifications. | |||
IANA has established the DKIM _domainkey DNS TXT Tag Specification | IANA has established the DKIM _domainkey DNS TXT Tag Specification | |||
Registry for tag specifications that can be used in DNS TXT resource | Registry for tag specifications that can be used in DNS TXT resource | |||
records. | records. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+----------+ | +------+-----------------+----------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
skipping to change at page 56, line 35 | skipping to change at page 56, line 8 | |||
| k | (this document) | active | | | k | (this document) | active | | |||
| n | (this document) | active | | | n | (this document) | active | | |||
| p | (this document) | active | | | p | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
| t | (this document) | active | | | t | (this document) | active | | |||
+------+-----------------+----------+ | +------+-----------------+----------+ | |||
DKIM _domainkey DNS TXT Tag Specification Registry | DKIM _domainkey DNS TXT Tag Specification Registry | |||
Updated Values | Updated Values | |||
7.5. DKIM Key Type Registry | 7.6. DKIM Key Type Registry | |||
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-k> (specified in Section 3.5) tags provide for a list of | a-tag-k> (specified in Section 3.5) tags provide for a list of | |||
mechanisms that can be used to decode a DKIM signature. | mechanisms that can be used to decode a DKIM signature. | |||
IANA has established the DKIM Key Type Registry for such mechanisms. | IANA has established the DKIM Key Type Registry for such mechanisms. | |||
The updated entry in the registry comprises: | The updated entry in the registry comprises: | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
| rsa | [RFC3447] | active | | | rsa | [RFC3447] | active | | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
DKIM Key Type Updated Values | DKIM Key Type Updated Values | |||
7.6. DKIM Hash Algorithms Registry | 7.7. DKIM Hash Algorithms Registry | |||
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-h> (specified in Section 3.5) tags provide for a list of | a-tag-h> (specified in Section 3.5) tags provide for a list of | |||
mechanisms that can be used to produce a digest of message data. | mechanisms that can be used to produce a digest of message data. | |||
IANA has established the DKIM Hash Algorithms Registry for such | IANA has established the DKIM Hash Algorithms Registry for such | |||
mechanisms. | mechanisms. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
| sha1 | [FIPS-180-3-2008] | active | | | sha1 | [FIPS-180-3-2008] | active | | |||
| sha256 | [FIPS-180-3-2008] | active | | | sha256 | [FIPS-180-3-2008] | active | | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
DKIM Hash Algorithms Updated Values | DKIM Hash Algorithms Updated Values | |||
7.7. DKIM Service Types Registry | 7.8. DKIM Service Types Registry | |||
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | |||
list of service types to which this selector may apply. | list of service types to which this selector may apply. | |||
IANA has established the DKIM Service Types Registry for service | IANA has established the DKIM Service Types Registry for service | |||
types. | types. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
| email | (this document) | active | | | email | (this document) | active | | |||
| * | (this document) | active | | | * | (this document) | active | | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
DKIM Service Types Registry Updated Values | DKIM Service Types Registry Updated Values | |||
7.8. DKIM Selector Flags Registry | 7.9. DKIM Selector Flags Registry | |||
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA has established the DKIM Selector Flags Registry for additional | IANA has established the DKIM Selector Flags Registry for additional | |||
flags. | flags. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| y | (this document) | active | | | y | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
DKIM Selector Flags Registry Updated Values | DKIM Selector Flags Registry Updated Values | |||
7.9. DKIM-Signature Header Field | 7.10. DKIM-Signature Header Field | |||
IANA has added DKIM-Signature to the "Permanent Message Header | IANA has added DKIM-Signature to the "Permanent Message Header | |||
Fields" registry (see [RFC3864]) for the "mail" protocol, using this | Fields" registry (see [RFC3864]) for the "mail" protocol, using this | |||
document as the reference. | document as the reference. | |||
8. Security Considerations | 8. Security Considerations | |||
It has been observed that any mechanism that is introduced that | It has been observed that any mechanism that is introduced that | |||
attempts to stem the flow of spam is subject to intensive attack. | attempts to stem the flow of spam is subject to intensive attack. | |||
DKIM needs to be carefully scrutinized to identify potential attack | DKIM needs to be carefully scrutinized to identify potential attack | |||
vectors and the vulnerability to each. See also [RFC4686]. | vectors and the vulnerability to each. See also [RFC4686]. | |||
8.1. Misuse of Body Length Limits ("l=" Tag) | 8.1. ASCII Art Attacks | |||
As noted in Section 3.4.5, use of the "l=" signature tag enables a | The relaxed body canonicalization algorithm may enable certain types | |||
variety of attacks in which added content can partially or completely | of extremely crude "ASCII Art" attacks where a message may be | |||
change the recipient's view of the message. | conveyed by adjusting the spacing between words. If this is a | |||
concern, the "simple" body canonicalization algorithm should be used | ||||
instead. | ||||
8.2. Misappropriated Private Key | 8.2. Misuse of Body Length Limits ("l=" Tag) | |||
If the private key for a user is resident on their computer and is | Use of the "l=" tag might allow display of fraudulent content without | |||
not protected by an appropriately secure mechanism, it is possible | appropriate warning to end users. The "l=" tag is intended for | |||
for malware to send mail as that user and any other user sharing the | increasing signature robustness when sending to mailing lists that | |||
same private key. The malware would not, however, be able to | both modify their content and do not sign their modified messages. | |||
generate signed spoofs of other signers' addresses, which would aid | However, using the "l=" tag enables attacks in which an intermediary | |||
in identification of the infected user and would limit the | with malicious intent modifies a message to include content that | |||
possibilities for certain types of attacks involving socially | solely benefits the attacker. It is possible for the appended | |||
engineered messages. This threat applies mainly to MUA-based | content to completely replace the original content in the end | |||
implementations; protection of private keys on servers can be easily | recipient's eyes and to defeat duplicate message detection | |||
achieved through the use of specialized cryptographic hardware. | algorithms. | |||
A larger problem occurs if malware on many users' computers obtains | An example of such an attack includes alterations to the MIME | |||
the private keys for those users and transmits them via a covert | structure or exploiting lax HTML parsing in the MUA, and to defeat | |||
channel to a site where they can be shared. The compromised users | duplicate message detection algorithms. | |||
would likely not know of the misappropriation until they receive | ||||
"bounce" messages from messages they are purported to have sent. | ||||
Many users might not understand the significance of these bounce | ||||
messages and would not take action. | ||||
One countermeasure is to use a user-entered passphrase to encrypt the | To avoid this attack, signers should be extremely wary of using this | |||
private key, although users tend to choose weak passphrases and often | tag, and assessors might wish to ignore signatures that use the tag. | |||
reuse them for different purposes, possibly allowing an attack | ||||
against DKIM to be extended into other domains. Nevertheless, the | ||||
decoded private key might be briefly available to compromise by | ||||
malware when it is entered, or might be discovered via keystroke | ||||
logging. The added complexity of entering a passphrase each time one | ||||
sends a message would also tend to discourage the use of a secure | ||||
passphrase. | ||||
A somewhat more effective countermeasure is to send messages through | 8.3. Misappropriated Private Key | |||
an outgoing MTA that can authenticate the submitter using existing | ||||
As with any other security application that uses private/public key | ||||
pairs, DKIM requires caution around the handling and protection of | ||||
keys. A compromised private key or access to one means an intruder | ||||
or malware can send mail signed by the domain that advertises the | ||||
matching public key. | ||||
Thus, private keys issued to users, rather than one used by an ADMD | ||||
itself, create the usual problem of securing data stored on personal | ||||
resources that can affect the ADMD. | ||||
A more secure architecture involves sending messages through an | ||||
outgoing MTA that can authenticate the submitter using existing | ||||
techniques (e.g., SMTP Authentication), possibly validate the message | techniques (e.g., SMTP Authentication), possibly validate the message | |||
itself (e.g., verify that the header is legitimate and that the | itself (e.g., verify that the header is legitimate and that the | |||
content passes a spam content check), and sign the message using a | content passes a spam content check), and sign the message using a | |||
key appropriate for the submitter address. Such an MTA can also | key appropriate for the submitter address. Such an MTA can also | |||
apply controls on the volume of outgoing mail each user is permitted | apply controls on the volume of outgoing mail each user is permitted | |||
to originate in order to further limit the ability of malware to | to originate in order to further limit the ability of malware to | |||
generate bulk email. | generate bulk email. | |||
8.3. Key Server Denial-of-Service Attacks | 8.4. Key Server Denial-of-Service Attacks | |||
Since the key servers are distributed (potentially separate for each | Since the key servers are distributed (potentially separate for each | |||
domain), the number of servers that would need to be attacked to | domain), the number of servers that would need to be attacked to | |||
defeat this mechanism on an Internet-wide basis is very large. | defeat this mechanism on an Internet-wide basis is very large. | |||
Nevertheless, key servers for individual domains could be attacked, | Nevertheless, key servers for individual domains could be attacked, | |||
impeding the verification of messages from that domain. This is not | impeding the verification of messages from that domain. This is not | |||
significantly different from the ability of an attacker to deny | significantly different from the ability of an attacker to deny | |||
service to the mail exchangers for a given domain, although it | service to the mail exchangers for a given domain, although it | |||
affects outgoing, not incoming, mail. | affects outgoing, not incoming, mail. | |||
A variation on this attack is that if a very large amount of mail | A variation on this attack involves a very large amount of mail being | |||
were to be sent using spoofed addresses from a given domain, the key | sent using spoofed signatures from a given domain, the key servers | |||
servers for that domain could be overwhelmed with requests. However, | for that domain could be overwhelmed with requests in a denial-of- | |||
given the low overhead of verification compared with handling of the | service attack (see [RFC4732]). However, given the low overhead of | |||
email message itself, such an attack would be difficult to mount. | verification compared with handling of the email message itself, such | |||
an attack would be difficult to mount. | ||||
8.4. Attacks Against the DNS | 8.5. Attacks Against the DNS | |||
Since the DNS is a required binding for key services, specific | Since the DNS is a required binding for key services, specific | |||
attacks against the DNS must be considered. | attacks against the DNS must be considered. | |||
While the DNS is currently insecure [RFC3833], these security | While the DNS is currently insecure [RFC3833], these security | |||
problems are the motivation behind DNS Security (DNSSEC) [RFC4033], | problems are the motivation behind DNS Security (DNSSEC) [RFC4033], | |||
and all users of the DNS will reap the benefit of that work. | and all users of the DNS will reap the benefit of that work. | |||
DKIM is only intended as a "sufficient" method of proving | DKIM is only intended as a "sufficient" method of proving | |||
authenticity. It is not intended to provide strong cryptographic | authenticity. It is not intended to provide strong cryptographic | |||
skipping to change at page 60, line 26 | skipping to change at page 60, line 5 | |||
A specific DNS security issue that should be considered by DKIM | A specific DNS security issue that should be considered by DKIM | |||
verifiers is the name chaining attack described in Section 2.3 of | verifiers is the name chaining attack described in Section 2.3 of | |||
[RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header | [RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header | |||
field, could be prompted to retrieve a key record of an attacker's | field, could be prompted to retrieve a key record of an attacker's | |||
choosing. This threat can be minimized by ensuring that name | choosing. This threat can be minimized by ensuring that name | |||
servers, including recursive name servers, used by the verifier | servers, including recursive name servers, used by the verifier | |||
enforce strict checking of "glue" and other additional information in | enforce strict checking of "glue" and other additional information in | |||
DNS responses and are therefore not vulnerable to this attack. | DNS responses and are therefore not vulnerable to this attack. | |||
8.5. Replay Attacks | 8.6. Replay/Spam Attacks | |||
In this attack, a spammer sends a message to be spammed to an | In this attack, a spammer sends a piece of spam through an MTA that | |||
accomplice, which results in the message being signed by the | signs it, banking on the reputation of the signing domain (e.g., a | |||
originating MTA. The accomplice resends the message, including the | large popular mailbox provider) rather than its own, and then re- | |||
original signature, to a large number of recipients, possibly by | sends that message to a large number of intended recipients. The | |||
sending the message to many compromised machines that act as MTAs. | recipients observe the valid signature from the well-known domain, | |||
The messages, not having been modified by the accomplice, have valid | elevating their trust in the message and increasing the likelihood of | |||
signatures. | delivery and presentation to the user. | |||
Partial solutions to this problem involve the use of reputation | Partial solutions to this problem involve the use of reputation | |||
services to convey the fact that the specific email address is being | services to convey the fact that the specific email address is being | |||
used for spam and that messages from that signer are likely to be | used for spam and that messages from that signer are likely to be | |||
spam. This requires a real-time detection mechanism in order to | spam. This requires a real-time detection mechanism in order to | |||
react quickly enough. However, such measures might be prone to | react quickly enough. However, such measures might be prone to | |||
abuse, if for example an attacker resent a large number of messages | abuse, if for example an attacker resent a large number of messages | |||
received from a victim in order to make them appear to be a spammer. | received from a victim in order to make them appear to be a spammer. | |||
Large verifiers might be able to detect unusually large volumes of | Large verifiers might be able to detect unusually large volumes of | |||
mails with the same signature in a short time period. Smaller | mails with the same signature in a short time period. Smaller | |||
verifiers can get substantially the same volume of information via | verifiers can get substantially the same volume of information via | |||
existing collaborative systems. | existing collaborative systems. | |||
8.6. Limits on Revoking Keys | 8.7. Limits on Revoking Keys | |||
When a large domain detects undesirable behavior on the part of one | When a large domain detects undesirable behavior on the part of one | |||
of its users, it might wish to revoke the key used to sign that | of its users, it might wish to revoke the key used to sign that | |||
user's messages in order to disavow responsibility for messages that | user's messages in order to disavow responsibility for messages that | |||
have not yet been verified or that are the subject of a replay | have not yet been verified or that are the subject of a replay | |||
attack. However, the ability of the domain to do so can be limited | attack. However, the ability of the domain to do so can be limited | |||
if the same key, for scalability reasons, is used to sign messages | if the same key, for scalability reasons, is used to sign messages | |||
for many other users. Mechanisms for explicitly revoking keys on a | for many other users. Mechanisms for explicitly revoking keys on a | |||
per-address basis have been proposed but require further study as to | per-address basis have been proposed but require further study as to | |||
their utility and the DNS load they represent. | their utility and the DNS load they represent. | |||
8.7. Intentionally Malformed Key Records | 8.8. Intentionally Malformed Key Records | |||
It is possible for an attacker to publish key records in DNS that are | It is possible for an attacker to publish key records in DNS that are | |||
intentionally malformed, with the intent of causing a denial-of- | intentionally malformed, with the intent of causing a denial-of- | |||
service attack on a non-robust verifier implementation. The attacker | service attack on a non-robust verifier implementation. The attacker | |||
could then cause a verifier to read the malformed key record by | could then cause a verifier to read the malformed key record by | |||
sending a message to one of its users referencing the malformed | sending a message to one of its users referencing the malformed | |||
record in a (not necessarily valid) signature. Verifiers MUST | record in a (not necessarily valid) signature. Verifiers MUST | |||
thoroughly verify all key records retrieved from the DNS and be | thoroughly verify all key records retrieved from the DNS and be | |||
robust against intentionally as well as unintentionally malformed key | robust against intentionally as well as unintentionally malformed key | |||
records. | records. | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields | 8.9. Intentionally Malformed DKIM-Signature Header Fields | |||
Verifiers MUST be prepared to receive messages with malformed DKIM- | Verifiers MUST be prepared to receive messages with malformed DKIM- | |||
Signature header fields, and thoroughly verify the header field | Signature header fields, and thoroughly verify the header field | |||
before depending on any of its contents. | before depending on any of its contents. | |||
8.9. Information Leakage | 8.10. Information Leakage | |||
An attacker could determine when a particular signature was verified | An attacker could determine when a particular signature was verified | |||
by using a per-message selector and then monitoring their DNS traffic | by using a per-message selector and then monitoring their DNS traffic | |||
for the key lookup. This would act as the equivalent of a "web bug" | for the key lookup. This would act as the equivalent of a "web bug" | |||
for verification time rather than when the message was read. | for verification time rather than when the message was read. | |||
8.10. Remote Timing Attacks | 8.11. Remote Timing Attacks | |||
In some cases it may be possible to extract private keys using a | In some cases it may be possible to extract private keys using a | |||
remote timing attack [BONEH03]. Implementations should consider | remote timing attack [BONEH03]. Implementations should consider | |||
obfuscating the timing to prevent such attacks. | obfuscating the timing to prevent such attacks. | |||
8.11. Reordered Header Fields | 8.12. Reordered Header Fields | |||
Existing standards allow intermediate MTAs to reorder header fields. | Existing standards allow intermediate MTAs to reorder header fields. | |||
If a signer signs two or more header fields of the same name, this | If a signer signs two or more header fields of the same name, this | |||
can cause spurious verification errors on otherwise legitimate | can cause spurious verification errors on otherwise legitimate | |||
messages. In particular, signers that sign any existing DKIM- | messages. In particular, signers that sign any existing DKIM- | |||
Signature fields run the risk of having messages incorrectly fail to | Signature fields run the risk of having messages incorrectly fail to | |||
verify. | verify. | |||
8.12. RSA Attacks | 8.13. RSA Attacks | |||
An attacker could create a large RSA signing key with a small | An attacker could create a large RSA signing key with a small | |||
exponent, thus requiring that the verification key have a large | exponent, thus requiring that the verification key have a large | |||
exponent. This will force verifiers to use considerable computing | exponent. This will force verifiers to use considerable computing | |||
resources to verify the signature. Verifiers might avoid this attack | resources to verify the signature. Verifiers might avoid this attack | |||
by refusing to verify signatures that reference selectors with public | by refusing to verify signatures that reference selectors with public | |||
keys having unreasonable exponents. | keys having unreasonable exponents. | |||
In general, an attacker might try to overwhelm a verifier by flooding | In general, an attacker might try to overwhelm a verifier by flooding | |||
it with messages requiring verification. This is similar to other | it with messages requiring verification. This is similar to other | |||
MTA denial-of-service attacks and should be dealt with in a similar | MTA denial-of-service attacks and should be dealt with in a similar | |||
fashion. | fashion. | |||
8.13. Inappropriate Signing by Parent Domains | 8.14. Inappropriate Signing by Parent Domains | |||
The trust relationship described in Section 3.10 could conceivably be | The trust relationship described in Section 3.10 could conceivably be | |||
used by a parent domain to sign messages with identities in a | used by a parent domain to sign messages with identities in a | |||
subdomain not administratively related to the parent. For example, | subdomain not administratively related to the parent. For example, | |||
the ".com" registry could create messages with signatures using an | the ".com" registry could create messages with signatures using an | |||
"i=" value in the example.com domain. There is no general solution | "i=" value in the example.com domain. There is no general solution | |||
to this problem, since the administrative cut could occur anywhere in | to this problem, since the administrative cut could occur anywhere in | |||
the domain name. For example, in the domain "example.podunk.ca.us" | the domain name. For example, in the domain "example.podunk.ca.us" | |||
there are three administrative cuts (podunk.ca.us, ca.us, and us), | there are three administrative cuts (podunk.ca.us, ca.us, and us), | |||
any of which could create messages with an identity in the full | any of which could create messages with an identity in the full | |||
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.14. Attacks Involving Addition of Header Fields | 8.15. Attacks Involving Addition of Header Fields | |||
Many email implementations do not enforce [RFC5322] with strictness. | ||||
As discussed in Section 5.3, DKIM processing is predicated on a valid | ||||
mail message as its input. However, DKIM implementers should be | ||||
aware of the potential effect of having loose enforcement by email | ||||
components interacting with DKIM modules. | ||||
For example, a message with multiple From: header fields violates | ||||
Section 3.6 of [RFC5322]. With the intent of providing a better user | ||||
experience, many agents tolerate these violations and deliver the | ||||
message anyway. An MUA then might elect to render to the user the | ||||
value of the first, or "top", From: field. This may also be done | ||||
simply out of the expectation that there is only one, where a "find | ||||
first" algorithm would have the same result. Such code in an MUA can | ||||
be exploited to fool the user if it is also known that the other | ||||
From: field is the one checked by arriving message filters. Such is | ||||
the case with DKIM; although the From: field must be signed, a | ||||
malformed message bearing more than one From: field might only have | ||||
the first ("bottom") one signed, in an attempt to show the message | ||||
with some "DKIM passed" annotation while also rendering the From: | ||||
field that was not authenticated. (This can also be taken as a | ||||
demonstration that DKIM is not designed to support author | ||||
validation.) | ||||
Note that the technique for using "h=...:from:from:...", described in | ||||
Section 8.15 below, is of no effect in the case of an attacker that | ||||
is also the signer. | ||||
The From: field is used above to illustrate this issue, but it is | ||||
only one of several fields that Section 3.6 of [RFC5322] constrains | ||||
in this way. In reality any agent that forgives such malformations, | ||||
or is careless about identifying which parts of a message were | ||||
authenticated, is open to exploitation. | ||||
8.15. Malformed Inputs | 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. | ||||
DKIM allows additional header fields to be added to a signed message | Many email components, including MTAs, MSAs, MUAs and filtering | |||
without breaking the signature. This tolerance can be abused, for | modules, implement message format checks only loosely. This is done | |||
example in a replay attack or a man-in-the-middle attack. The attack | out of years of industry pressure to be liberal in what is accepted | |||
is accomplished by creating additional instances of header fields to | into the mail stream for the sake of reducing support costs; | |||
an already signed message, without breaking the signature. These | improperly formed messages are often silently fixed in transit or | |||
then might be displayed to the end user or are used as filtering | even delivered unrepaired. | |||
input. Applicable fields might include From: and Subject:. | ||||
The resulting message violates section 3.6 of [RFC5322]. The way | DKIM signs and validates the data it is told to and works correctly. | |||
such input will be handled and displayed by an MUA is unpredictable, | So in this case, DKIM has done its job of delivering a validated | |||
but it will commonly display the newly added header fields rather | domain (the "d=" value) and, given the semantics of a DKIM signature, | |||
than those that are part of the originally signed message alongside | essentially the signer has taken some responsibility for a | |||
some "valid DKIM signature" annotation. This might allow an attacker | problematic message. The verifier or receiver is able to act on this | |||
to replay a previously sent, signed message with a different | information as needed, such as degrading the trust of the message | |||
Subject:, From: or To: field. | (or, indeed, of the signer). | |||
However, [RFC5322] also tolerates obsolete message syntax, which does | An agent consuming DKIM results needs to be aware that the validity | |||
allow things like multiple From: fields on messages. The | of any header field, signed or otherwise, is not guaranteed by DKIM. | |||
implementation of DKIM thus potentially creates a more stringent | ||||
layer of expectation regarding the meaning of an identity, while that | ||||
additional meaning is either obscured from or incorrectly presented | ||||
to an end user in this context. | ||||
Implementers need to consider this possibility when designing their | At the same time, DKIM can aid in detecting addition of specific | |||
input handling functions. Outright rejection of messages that | fields in transit. This is done by having the signer list the field | |||
violate the relevant standards such as [RFC5322], [RFC2045], etc. | name(s) in the "h=" tag an extra time (e.g., "h=from:from:..." for a | |||
will interfere with delivery of legacy formats. Instead, given such | message with one From field), so that addition of an instance of that | |||
input, a signing module could return an error rather than generate a | field downstream will render the signature unable to be verified. | |||
signature; a verifying module might return a syntax error code or | ||||
arrange not to return a positive result even if the signature | ||||
technically validates. | ||||
Senders concerned that their messages might be particularly | (See Section 3.5 for details.) This in essence is an explicit | |||
vulnerable to this sort of attack and who do not wish to rely on | indication that the signer does not wish to take any responsibility | |||
receiver filtering of invalid messages can ensure that adding | for such a malformed message. | |||
additional header fields will break the DKIM signature by including | ||||
two copies of the header fields about which they are concerned in the | ||||
signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | ||||
Sections 3.5 and 5.4 for further discussion of this mechanism. | ||||
Specific validity rules for all known header fields can be gleaned | Components of the mail system that perform loose enforcement of other | |||
from the IANA "Permanent Header Field Registry" and the reference | mail standards will need to revisit that posture when incorporating | |||
documents it identifies. | DKIM, especially when considering matters of potential attacks on | |||
receivers. | ||||
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] | |||
skipping to change at page 65, line 34 | skipping to change at page 64, line 24 | |||
9.2. Informative References | 9.2. Informative References | |||
[BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th | [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th | |||
USENIX Security Symposium, 2003. | USENIX Security Symposium, 2003. | |||
[I-D.DKIM-MAILINGLISTS] | [I-D.DKIM-MAILINGLISTS] | |||
Kucherawy, M., "DKIM And Mailing Lists", | Kucherawy, M., "DKIM And Mailing Lists", | |||
I-D draft-ietf-dkim-mailinglists, June 2011. | I-D draft-ietf-dkim-mailinglists, June 2011. | |||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | ||||
10646", RFC 3629, June 2011. | ||||
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | |||
Public Keys Used For Exchanging Symmetric Keys", BCP 86, | Public Keys Used For Exchanging Symmetric Keys", BCP 86, | |||
RFC 3766, April 2004. | RFC 3766, April 2004. | |||
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | |||
Name System (DNS)", RFC 3833, August 2004. | Name System (DNS)", RFC 3833, August 2004. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004. | September 2004. | |||
skipping to change at page 66, line 6 | skipping to change at page 64, line 48 | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, March 2005. | RFC 4033, March 2005. | |||
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", | [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", | |||
RFC 4409, April 2006. | RFC 4409, April 2006. | |||
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys | [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys | |||
Identified Mail (DKIM)", RFC 4686, September 2006. | Identified Mail (DKIM)", RFC 4686, September 2006. | |||
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet | ||||
Denial-of-Service Considerations", RFC 4732, | ||||
November 2006. | ||||
[RFC4870] Delany, M., "Domain-Based Email Authentication Using | [RFC4870] Delany, M., "Domain-Based Email Authentication Using | |||
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, | Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, | |||
May 2007. | May 2007. | |||
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | |||
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | |||
Signatures", RFC 4871, May 2007. | Signatures", RFC 4871, May 2007. | |||
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | |||
"OpenPGP Message Format", RFC 4880, November 2007. | "OpenPGP Message Format", RFC 4880, November 2007. | |||
skipping to change at page 71, line 25 | skipping to change at page 70, line 25 | |||
the Sender field. This provides useful information to the receiving | the Sender field. This provides useful information to the receiving | |||
email site, which is able to correlate the signing domain with the | email site, which is able to correlate the signing domain with the | |||
initial submission email role. | initial submission email role. | |||
Receiving sites often wish to provide their end users with | Receiving sites often wish to provide their end users with | |||
information about mail that is mediated in this fashion. Although | information about mail that is mediated in this fashion. Although | |||
the real efficacy of different approaches is a subject for human | the real efficacy of different approaches is a subject for human | |||
factors usability research, one technique that is used is for the | factors usability research, one technique that is used is for the | |||
verifying system to rewrite the From header field, to indicate the | verifying system to rewrite the From header field, to indicate the | |||
address that was verified. For example: From: John Doe via | address that was verified. For example: From: John Doe via | |||
news@news-site.com <jdoe@example.com>. (Note that such rewriting | news@news-site.example <jdoe@example.com>. (Note that such rewriting | |||
will break a signature, unless it is done after the verification pass | will break a signature, unless it is done after the verification pass | |||
is complete.) | is complete.) | |||
B.2. Alternate Delivery Scenarios | B.2. Alternate Delivery Scenarios | |||
Email is often received at a mailbox that has an address different | Email is often received at a mailbox that has an address different | |||
from the one used during initial submission. In these cases, an | from the one used during initial submission. In these cases, an | |||
intermediary mechanism operates at the address originally used and it | intermediary mechanism operates at the address originally used and it | |||
then passes the message on to the final destination. This mediation | then passes the message on to the final destination. This mediation | |||
process presents some challenges for DKIM signatures. | process presents some challenges for DKIM signatures. | |||
skipping to change at page 74, line 36 | skipping to change at page 73, line 36 | |||
C.1. Compatibility with DomainKeys Key Records | C.1. Compatibility with DomainKeys Key Records | |||
DKIM key records were designed to be backwards-compatible in many | DKIM key records were designed to be backwards-compatible in many | |||
cases with key records used by DomainKeys [RFC4870] (sometimes | cases with key records used by DomainKeys [RFC4870] (sometimes | |||
referred to as "selector records" in the DomainKeys context). One | referred to as "selector records" in the DomainKeys context). One | |||
area of incompatibility warrants particular attention. The "g=" tag/ | area of incompatibility warrants particular attention. The "g=" tag/ | |||
value may be used in DomainKeys and [RFC4871] key records to provide | value may be used in DomainKeys and [RFC4871] key records to provide | |||
finer granularity of the validity of the key record to a specific | finer granularity of the validity of the key record to a specific | |||
local-part. A null "g=" value in DomainKeys is valid for all | local-part. A null "g=" value in DomainKeys is valid for all | |||
addresses in the domain. This differs from the usage in the original | addresses in the domain. This differs from the usage in the original | |||
DKIM specification, where a null "g=" value is not valid for any | DKIM specification ([RFC4871]), where a null "g=" value is not valid | |||
address. In particular, the example public key record in Section | for any address. In particular, see the example public key record in | |||
3.2.3 of [RFC4870] with DKIM. | Section 3.2.3 of [RFC4870]. | |||
C.2. RFC4871 Compatibility | C.2. RFC4871 Compatibility | |||
Although the "g=" tag has been deprecated in this version of the DKIM | Although the "g=" tag has been deprecated in this version of the DKIM | |||
specification (and thus MUST now be ignored), signers are advised not | specification (and thus MUST now be ignored), signers are advised not | |||
to include the "g=" tag in key records because some [RFC4871]- | to include the "g=" tag in key records because some [RFC4871]- | |||
compliant verifiers will be in use for a considerable period to come. | compliant verifiers will be in use for a considerable period to come. | |||
Appendix D. MUA Considerations (INFORMATIVE) | Appendix D. MUA Considerations (INFORMATIVE) | |||
skipping to change at page 75, line 23 | skipping to change at page 74, line 23 | |||
signed header fields, with a negative indication on the unsigned | signed header fields, with a negative indication on the unsigned | |||
header fields, by visually hiding the unsigned header fields, or some | header fields, by visually hiding the unsigned header fields, or some | |||
combination of these. If an MUA uses visual indications for signed | combination of these. If an MUA uses visual indications for signed | |||
header fields, the MUA probably needs to be careful not to display | header fields, the MUA probably needs to be careful not to display | |||
unsigned header fields in a way that might be construed by the end | unsigned header fields in a way that might be construed by the end | |||
user as having been signed. If the message has an l= tag whose value | user as having been signed. If the message has an l= tag whose value | |||
does not extend to the end of the message, the MUA might also hide or | does not extend to the end of the message, the MUA might also hide or | |||
mark the portion of the message body that was not signed. | mark the portion of the message body that was not signed. | |||
The aforementioned information is not intended to be exhaustive. The | The aforementioned information is not intended to be exhaustive. The | |||
MUA may choose to highlight, accentuate, hide, or otherwise display | MUA can choose to highlight, accentuate, hide, or otherwise display | |||
any other information that may, in the opinion of the MUA author, be | any other information that may, in the opinion of the MUA author, be | |||
deemed important to the end user. | deemed important to the end user. | |||
Appendix E. Changes since RFC4871 | Appendix E. Changes since RFC4871 | |||
o Abstract and introduction refined based on accumulated experience. | o Abstract and introduction refined based on accumulated experience. | |||
o Various references updated. | o Various references updated. | |||
o Several errata resolved: | o Several errata resolved (see | |||
http://www.rfc-editor.org/errata_search.php?rfc=4871): | ||||
* 1376 applied | * 1376 applied | |||
* 1377 applied | * 1377 applied | |||
* 1378 applied | * 1378 applied | |||
* 1379 applied | * 1379 applied | |||
* 1380 applied | * 1380 applied | |||
End of changes. 102 change blocks. | ||||
452 lines changed or deleted | 402 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/ |