draft-ietf-dkim-rfc4871bis-09.txt | draft-ietf-dkim-rfc4871bis-10.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: November 2, 2011 Cloudmark | Expires: November 12, 2011 Cloudmark | |||
May 1, 2011 | May 11, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-09 | draft-ietf-dkim-rfc4871bis-10 | |||
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 November 2, 2011. | This Internet-Draft will expire on November 12, 2011. | |||
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 2, line 43 | skipping to change at page 2, line 43 | |||
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 . . . . . . . . . . . . 28 | 3.6. Key Management and Representation . . . . . . . . . . . . 28 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | |||
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | |||
3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 35 | 3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 35 | |||
3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 | 3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 38 | 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.2. Select a Private Key and Corresponding Selector | 5.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 40 | Information . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
5.3. Normalize the Message to Prevent Transport Conversions . . 40 | 5.3. Normalize the Message to Prevent Transport Conversions . . 40 | |||
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | |||
5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | 5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 45 | 5.6. Compute the Message Hash and Signature . . . . . . . . . . 45 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | |||
6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | 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 . . . . . . . . . . . . . . . . . . . . . 53 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | |||
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | |||
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | |||
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | |||
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 | 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | |||
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | |||
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | |||
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 | 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | |||
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | |||
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | |||
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57 | 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | |||
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 | 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 | |||
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58 | 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | |||
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 | 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 | |||
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 59 | 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 | |||
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 | 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 | 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 | |||
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60 | 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | |||
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60 | 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | |||
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60 | 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | |||
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 | 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 | 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 | |||
8.14. Attacks Involving Addition of Header Fields . . . . . . . 61 | 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | |||
8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 62 | 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 62 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 64 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | |||
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | |||
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 | |||
A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | |||
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 73 | C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 73 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | |||
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 | |||
public key. Message transit from author to recipient is through | public key. Message transit from author to recipient is through | |||
relays that typically make no substantive change to the message | relays that typically make no substantive change to the message | |||
content and thus preserve the DKIM signature. A message can contain | content and thus preserve the DKIM signature. A message can contain | |||
multiple signatures, from the same or different organizations | multiple signatures, from the same or different organizations | |||
involved with the message. | involved with the message. | |||
The approach taken by DKIM differs from previous approaches to | The approach taken by DKIM differs from previous approaches to | |||
message signing (e.g., Secure/Multipurpose Internet Mail Extensions | message signing (e.g., Secure/Multipurpose Internet Mail Extensions | |||
(S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: | (S/MIME) [RFC5751], OpenPGP [RFC4880]) in that: | |||
o the message signature is written as a message header field so that | o the message signature is written as a message header field so that | |||
neither human recipients nor existing MUA (Mail User Agent) | neither human recipients nor existing MUA (Mail User Agent) | |||
software is confused by signature-related content appearing in the | software is confused by signature-related content appearing in the | |||
message body; | message body; | |||
o there is no dependency on public and private key pairs being | o there is no dependency on public and private key pairs being | |||
issued by well-known, trusted certificate authorities; | issued by well-known, trusted certificate authorities; | |||
o there is no dependency on the deployment of any new Internet | o there is no dependency on the deployment of any new Internet | |||
skipping to change at page 7, line 26 | skipping to change at page 7, line 26 | |||
This section defines terms used in the rest of the document. | This section defines terms used in the rest of the document. | |||
DKIM is designed to operate within the Internet Mail service, as | DKIM is designed to operate within the Internet Mail service, as | |||
defined in [RFC5598]. Basic email terminology is taken from that | defined in [RFC5598]. Basic email terminology is taken from that | |||
specification. | specification. | |||
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. | Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. These | |||
words take their normative meanings only when they are presented in | ||||
ALL UPPER CASE. | ||||
2.1. Signers | 2.1. Signers | |||
Elements in the mail system that sign messages on behalf of a domain | Elements in the mail system that sign messages on behalf of a domain | |||
are referred to as signers. These may be MUAs (Mail User Agents), | are referred to as signers. These may be MUAs (Mail User Agents), | |||
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other | MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other | |||
agents such as mailing list exploders. In general, any signer will | agents such as mailing list exploders. In general, any signer will | |||
be involved in the injection of a message into the message system in | be involved in the injection of a message into the message system in | |||
some way. The key issue is that a message must be signed before it | some way. The key issue is that a message must be signed before it | |||
leaves the administrative domain of the signer. | leaves the administrative domain of the signer. | |||
skipping to change at page 8, line 26 | skipping to change at page 8, line 28 | |||
A single identifier that refers to the agent or user on behalf of | A single identifier that refers to the agent or user on behalf of | |||
whom the Signing Domain Identifier (SDID) has taken responsibility. | whom the Signing Domain Identifier (SDID) has taken responsibility. | |||
The AUID comprises a domain name and an optional <Local-part>. The | The AUID comprises a domain name and an optional <Local-part>. The | |||
domain name is the same as that used for the SDID or is a sub-domain | domain name is the same as that used for the SDID or is a sub-domain | |||
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 the constraint on the value of "i=" that can be imposed by the | ||||
"t=s" tag of the stored 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 | A module that consumes DKIM's mandatory payload, which is the | |||
responsible Signing Domain Identifier (SDID). The module is | responsible Signing Domain Identifier (SDID). The module is | |||
dedicated to the assessment of the delivered identifier. Other DKIM | dedicated to the assessment of the delivered identifier. Other DKIM | |||
(and non-DKIM) values can also be delivered to this module as well as | (and non-DKIM) values can also be delivered to this module as well as | |||
to a more general message evaluation filtering engine. However, this | to a more general message evaluation filtering engine. However, this | |||
additional activity is outside the scope of the DKIM signature | additional activity is outside the scope of the DKIM signature | |||
specification. | specification. | |||
skipping to change at page 14, line 16 | skipping to change at page 14, line 16 | |||
Tags that have an empty value are not the same as omitted tags. An | Tags that have an empty value are not the same as omitted tags. An | |||
omitted tag is treated as having the default value; a tag with an | omitted tag is treated as having the default value; a tag with an | |||
empty value explicitly designates the empty string as the value. | empty value explicitly designates the empty string as the value. | |||
3.3. Signing and Verification Algorithms | 3.3. Signing and Verification Algorithms | |||
DKIM supports multiple digital signature algorithms. Two algorithms | DKIM supports multiple digital signature algorithms. Two algorithms | |||
are defined by this specification at this time: rsa-sha1 and rsa- | are defined by this specification at this time: rsa-sha1 and rsa- | |||
sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | |||
Verifiers MUST implement rsa-sha256. | Verifiers MUST implement both rsa-sha1 and rsa-sha256. | |||
INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some | INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some | |||
senders might prefer to use rsa-sha1 when balancing security | senders might prefer to use rsa-sha1 when balancing security | |||
strength against performance, complexity, or other needs. | strength against performance, complexity, or other needs. In | |||
However, compliant verifiers might not implement rsa-sha1; they | general, however, rsa-sha256 should always be used whenever | |||
will treat such messages as unsigned. | possible. | |||
3.3.1. The rsa-sha1 Signing Algorithm | 3.3.1. The rsa-sha1 Signing Algorithm | |||
The rsa-sha1 Signing Algorithm computes a message hash as described | The rsa-sha1 Signing Algorithm computes a message hash as described | |||
in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. | in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. | |||
That hash is then signed by the signer using the RSA algorithm | That hash is then signed by the signer using the RSA algorithm | |||
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the | (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the | |||
signer's private key. The hash MUST NOT be truncated or converted | signer's private key. The hash MUST NOT be truncated or converted | |||
into any form other than the native binary form before being signed. | into any form other than the native binary form before being signed. | |||
The signing algorithm SHOULD use a public exponent of 65537. | The signing algorithm SHOULD use a public exponent of 65537. | |||
skipping to change at page 20, line 42 | skipping to change at page 20, line 42 | |||
ABNF: | ABNF: | |||
sig-v-tag = %x76 [FWS] "=" [FWS] "1" | sig-v-tag = %x76 [FWS] "=" [FWS] "1" | |||
INFORMATIVE NOTE: DKIM-Signature version numbers are expected | INFORMATIVE NOTE: DKIM-Signature version numbers are expected | |||
to increase arithmetically as new versions of this | to increase arithmetically as new versions of this | |||
specification are released. | specification are 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". | signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | |||
description of the algorithms. | ||||
ABNF: | ABNF: | |||
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | |||
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | |||
sig-a-tag-k = "rsa" / x-sig-a-tag-k | sig-a-tag-k = "rsa" / x-sig-a-tag-k | |||
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h | sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h | |||
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | |||
; for later extension | ; for later extension | |||
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) | x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) | |||
skipping to change at page 25, line 17 | skipping to change at page 25, line 26 | |||
allow display of fraudulent content without appropriate warning | allow display of fraudulent content without appropriate warning | |||
to end users. The "l=" tag is intended for increasing | to end users. The "l=" tag is intended for increasing | |||
signature robustness when sending to mailing lists that both | signature robustness when sending to mailing lists that both | |||
modify their content and do not sign their messages. However, | modify their content and do not sign their messages. However, | |||
using the "l=" tag enables attacks in which an intermediary | using the "l=" tag enables attacks in which an intermediary | |||
with malicious intent modifies a message to include content | with malicious intent modifies a message to include content | |||
that solely benefits the attacker. It is possible for the | that solely benefits the attacker. It is possible for the | |||
appended content to completely replace the original content in | appended content to completely replace the original content in | |||
the end recipient's eyes and to defeat duplicate message | the end recipient's eyes and to defeat duplicate message | |||
detection algorithms. Examples are described in Security | detection algorithms. Examples are described in Security | |||
Considerations Section 8. To avoid this attack, signers should | Considerations (Section 8). To avoid this attack, signers | |||
be extremely wary of using this tag, and verifiers might wish | should be extremely wary of using this tag, and assessors might | |||
to ignore the tag. | 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 34 | skipping to change at page 30, line 41 | |||
p= Public-key data (base64; REQUIRED). An empty value means that | p= Public-key data (base64; REQUIRED). An empty value means that | |||
this public key has been revoked. The syntax and semantics of | this public key has been revoked. The syntax and semantics of | |||
this tag value before being encoded in base64 are defined by the | this tag value before being encoded in base64 are defined by the | |||
"k=" tag. | "k=" tag. | |||
INFORMATIVE RATIONALE: If a private key has been compromised or | INFORMATIVE RATIONALE: If a private key has been compromised or | |||
otherwise disabled (e.g., an outsourcing contract has been | otherwise disabled (e.g., an outsourcing contract has been | |||
terminated), a signer might want to explicitly state that it | terminated), a signer might want to explicitly state that it | |||
knows about the selector, but all messages using that selector | knows about the selector, but all messages using that selector | |||
should fail verification. Verifiers should ignore any DKIM- | should fail verification. Verifiers SHOULD return an error | |||
Signature header fields with a selector referencing a revoked | code for any DKIM-Signature header field with a selector | |||
key. | referencing a revoked key. (See Section 6.1.2 for details.) | |||
ABNF: | ABNF: | |||
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] | key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] | |||
INFORMATIVE NOTE: A base64string is permitted to include white | INFORMATIVE NOTE: A base64string is permitted to include white | |||
space (FWS) at arbitrary places; however, any CRLFs must be | space (FWS) at arbitrary places; however, any CRLFs must be | |||
followed by at least one WSP character. Implementors and | followed by at least one WSP character. Implementors and | |||
administrators are cautioned to ensure that selector TXT | administrators are cautioned to ensure that selector TXT | |||
records conform to this specification. | records conform to this specification. | |||
skipping to change at page 32, line 45 | skipping to change at page 33, line 10 | |||
selector name; that is, if there are multiple records in an RRset, | selector name; that is, if there are multiple records in an RRset, | |||
the results are undefined. | the results are undefined. | |||
TXT RRs are encoded as described in Section 3.6.1 | TXT RRs are encoded as described in Section 3.6.1 | |||
3.7. Computing the Message Hashes | 3.7. Computing the Message Hashes | |||
Both signing and verifying message signatures start with a step of | Both signing and verifying message signatures start with a step of | |||
computing two cryptographic hashes over the message. Signers will | computing two cryptographic hashes over the message. Signers will | |||
choose the parameters of the signature as described in Signer Actions | choose the parameters of the signature as described in Signer Actions | |||
Section 5; verifiers will use the parameters specified in the DKIM- | (Section 5); verifiers will use the parameters specified in the DKIM- | |||
Signature header field being verified. In the following discussion, | Signature header field being verified. In the following discussion, | |||
the names of the tags in the DKIM-Signature header field that either | the names of the tags in the DKIM-Signature header field that either | |||
exists (when verifying) or will be created (when signing) are used. | exists (when verifying) or will be created (when signing) are used. | |||
Note that canonicalization (Section 3.4) is only used to prepare the | Note that canonicalization (Section 3.4) is only used to prepare the | |||
email for signing or verifying; it does not affect the transmitted | email for signing or verifying; it does not affect the transmitted | |||
email in any way. | email in any way. | |||
The signer/verifier MUST compute two hashes, one over the body of the | The signer/verifier MUST compute two hashes, one over the body of the | |||
message and one over the selected header fields of the message. | message and one over the selected header fields of the message. | |||
skipping to change at page 39, line 19 | skipping to change at page 39, line 28 | |||
signatures corresponding to the From field in the message header | signatures corresponding to the From field in the message header | |||
before other signatures. See Section 6.1 for more information about | before other signatures. See Section 6.1 for more information about | |||
signature choices. | signature choices. | |||
INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate | INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate | |||
valid signatures with invalid signatures in an attempt to guess | valid signatures with invalid signatures in an attempt to guess | |||
why a signature failed are ill-advised. In particular, there is | why a signature failed are ill-advised. In particular, there is | |||
no general way that a verifier can determine that an invalid | no general way that a verifier can determine that an invalid | |||
signature was ever valid. | signature was ever valid. | |||
Verifiers SHOULD ignore those signatures that produce a PERMFAIL | Verifiers SHOULD continue to check signatures until a signature | |||
result (see Section 6.1), acting as though they were not present in | successfully verifies to the satisfaction of the verifier. To limit | |||
the message. Verifiers SHOULD continue to check signatures until a | potential denial-of-service attacks, verifiers MAY limit the total | |||
signature successfully verifies to the satisfaction of the verifier. | number of signatures they will attempt to verify. | |||
To limit potential denial-of-service attacks, verifiers MAY limit the | ||||
total number of signatures they will attempt to verify. | If a verifier module reports signatures whose evaluations produced | |||
PERMFAIL results, identity assessors SHOULD ignore those signatures | ||||
(see Section 6.1), acting as though they were not present in the | ||||
message. | ||||
5. Signer Actions | 5. Signer Actions | |||
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 | |||
skipping to change at page 44, line 15 | skipping to change at page 44, line 28 | |||
Including fields such as "Message-ID" for example is useful if one | Including fields such as "Message-ID" for example is useful if one | |||
considers a mechanism for being able to distinguish separate | considers a mechanism for being able to distinguish separate | |||
instances of the same message to be core content. Similarly, "In- | instances of the same message to be core content. Similarly, "In- | |||
Reply-To" and "References" might be desirable to include if one | Reply-To" and "References" might be desirable to include if one | |||
considers message threading to be a core part of the message. | considers message threading to be a core part of the message. | |||
Another class of fields that may be of interest are those that convey | Another class of fields that may be of interest are those that convey | |||
security-related information about the message, such as | security-related information about the message, such as | |||
Authentication-Results [RFC5451]. | Authentication-Results [RFC5451]. | |||
The basic rule for choosing field to exclude is to select those | The basic rule for choosing fields to exclude is to select those | |||
fields for which there are multiple fields with the same name, and | fields for which there are multiple fields with the same name, and | |||
fields that are modified in transit. Examples of these are: | fields that are modified in transit. Examples of these are: | |||
o Return-Path | o Return-Path | |||
o Received | o Received | |||
o Comments, Keywords | o Comments, Keywords | |||
Note that the DKIM-Signature field is also excluded from the header | Note that the DKIM-Signature field is also excluded from the header | |||
skipping to change at page 47, line 29 | skipping to change at page 47, line 43 | |||
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 | |||
signature; if no good signature is found and any of the signatures | signature; if no good signature is found and any of the signatures | |||
resulted in a TEMPFAIL status, the verifier MAY arrange to defer the | resulted in a TEMPFAIL status, the verifier MAY arrange to defer the | |||
message for later processing. The "(explanation)" is not normative | message for later processing. The "(explanation)" is not normative | |||
text; it is provided solely for clarification. | text; it is provided solely for clarification. | |||
Verifiers SHOULD ignore any DKIM-Signature header fields where the | Verifiers that are prepared to validate multiple signature header | |||
signature does not validate. Verifiers that are prepared to validate | fields SHOULD proceed to the next signature header field, if one | |||
multiple signature header fields SHOULD proceed to the next signature | exists. However, verifiers MAY make note of the fact that an invalid | |||
header field, if one exists. However, verifiers MAY make note of the | signature was present for consideration at a later step. | |||
fact that an invalid signature was present for consideration at a | ||||
later step. | ||||
INFORMATIVE NOTE: The rationale of this requirement is to permit | INFORMATIVE NOTE: The rationale of this requirement is to permit | |||
messages that have invalid signatures but also a valid signature | messages that have invalid signatures but also a valid signature | |||
to work. For example, a mailing list exploder might opt to leave | to work. For example, a mailing list exploder might opt to leave | |||
the original submitter signature in place even though the exploder | the original submitter signature in place even though the exploder | |||
knows that it is modifying the message in some way that will break | knows that it is modifying the message in some way that will break | |||
that signature, and the exploder inserts its own signature. In | that signature, and the exploder inserts its own signature. In | |||
this case, the message should succeed even in the presence of the | this case, the message should succeed even in the presence of the | |||
known-broken signature. | known-broken signature. | |||
skipping to change at page 48, line 9 | skipping to change at page 48, line 21 | |||
6.1.1. Validate the Signature Header Field | 6.1.1. Validate the Signature Header Field | |||
Implementers MUST meticulously validate the format and values in the | Implementers MUST meticulously validate the format and values in the | |||
DKIM-Signature header field; any inconsistency or unexpected values | DKIM-Signature header field; any inconsistency or unexpected values | |||
MUST cause the header field to be completely ignored and the verifier | MUST cause the header field to be completely ignored and the verifier | |||
to return PERMFAIL (signature syntax error). Being "liberal in what | to return PERMFAIL (signature syntax error). Being "liberal in what | |||
you accept" is definitely a bad strategy in this security context. | you accept" is definitely a bad strategy in this security context. | |||
Note however that this does not include the existence of unknown tags | Note however that this does not include the existence of unknown tags | |||
in a DKIM-Signature header field, which are explicitly permitted. | in a DKIM-Signature header field, which are explicitly permitted. | |||
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag | Verifiers MUST return PERMFAIL (incompatible version) when presented | |||
that is inconsistent with this specification and return PERMFAIL | a DKIM-Signature header field with a "v=" tag that is inconsistent | |||
(incompatible version). | with this specification. | |||
INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, | INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, | |||
choose to also verify signatures generated by older versions of | choose to also verify signatures generated by older versions of | |||
this specification. | this specification. | |||
If any tag listed as "required" in Section 3.5 is omitted from the | If any tag listed as "required" in Section 3.5 is omitted from the | |||
DKIM-Signature header field, the verifier MUST ignore the DKIM- | DKIM-Signature header field, the verifier MUST ignore the DKIM- | |||
Signature header field and return PERMFAIL (signature missing | Signature header field and return PERMFAIL (signature missing | |||
required tag). | required tag). | |||
skipping to change at page 61, line 43 | skipping to change at page 62, line 16 | |||
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.14. Attacks Involving Addition of Header Fields | |||
Many email implementations do not enforce [RFC5322] with strictness. | Many email implementations do not enforce [RFC5322] with strictness. | |||
As discussed in Section 5.3 DKIM processing is predicated on a valid | As discussed in Section 5.3, DKIM processing is predicated on a valid | |||
mail message as its input. However, DKIM implementers should be | mail message as its input. However, DKIM implementers should be | |||
aware of the potential effect of having loose enforcement by email | aware of the potential effect of having loose enforcement by email | |||
components interacting with DKIM modules. | components interacting with DKIM modules. | |||
For example, a message with multiple From: header fields violates | For example, a message with multiple From: header fields violates | |||
Section 3.6 of [RFC5322]. With the intent of providing a better user | Section 3.6 of [RFC5322]. With the intent of providing a better user | |||
experience, many agents tolerate these violations and deliver the | experience, many agents tolerate these violations and deliver the | |||
message anyway. An MUA then might elect to render to the user 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 | 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 | simply out of the expectation that there is only one, where a "find | |||
skipping to change at page 62, line 34 | skipping to change at page 63, line 7 | |||
authenticated, is open to exploitation. | authenticated, is open to exploitation. | |||
8.15. Malformed Inputs | 8.15. Malformed Inputs | |||
DKIM allows additional header fields to be added to a signed message | DKIM allows additional header fields to be added to a signed message | |||
without breaking the signature. This tolerance can be abused, for | without breaking the signature. This tolerance can be abused, for | |||
example in a replay attack or a man-in-the-middle attack. The attack | example in a replay attack or a man-in-the-middle attack. The attack | |||
is accomplished by creating additional instances of header fields to | is accomplished by creating additional instances of header fields to | |||
an already signed message, without breaking the signature. These | an already signed message, without breaking the signature. These | |||
then might be displayed to the end user or are used as filtering | then might be displayed to the end user or are used as filtering | |||
input. Salient fields could include From: and Subject:, | input. Applicable fields might include From: and Subject:. | |||
The resulting message violates section 3.6 of [RFC5322]. The way | The resulting message violates section 3.6 of [RFC5322]. The way | |||
such input will be handled and displayed by an MUA is unpredictable, | such input will be handled and displayed by an MUA is unpredictable, | |||
but it will commonly display the newly added header fields rather | but it will commonly display the newly added header fields rather | |||
than those that are part of the originally signed message alongside | than those that are part of the originally signed message alongside | |||
some "valid DKIM signature" annotation. This might allow an attacker | some "valid DKIM signature" annotation. This might allow an attacker | |||
to replay a previously sent, signed message with a different | to replay a previously sent, signed message with a different | |||
Subject:, From: or To: field. | Subject:, From: or To: field. | |||
However, [RFC5322] also tolerates obsolete message syntax, which does | However, [RFC5322] also tolerates obsolete message syntax, which does | |||
skipping to change at page 64, line 30 | skipping to change at page 64, line 51 | |||
[RFC5890] Klensin, J., "Internationalizing Domain Names in | [RFC5890] Klensin, J., "Internationalizing Domain Names in | |||
Applications (IDNA): Definitions and Document Framework", | Applications (IDNA): Definitions and Document Framework", | |||
RFC 5890, August 2010. | RFC 5890, August 2010. | |||
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. | |||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | ||||
"Security Multiparts for MIME: Multipart/Signed and | ||||
Multipart/Encrypted", RFC 1847, October 1995. | ||||
[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 4 | skipping to change at page 66, line 13 | |||
"DomainKeys Identified Mail (DKIM) Development, | "DomainKeys Identified Mail (DKIM) Development, | |||
Deployment, and Operations", RFC 5863, May 2010. | Deployment, and Operations", RFC 5863, May 2010. | |||
Appendix A. Example of Use (INFORMATIVE) | Appendix A. Example of Use (INFORMATIVE) | |||
This section shows the complete flow of an email from submission to | This section shows the complete flow of an email from submission to | |||
final delivery, demonstrating how the various components fit | final delivery, demonstrating how the various components fit | |||
together. The key used in this example is shown in Appendix C. | together. The key used in this example is shown in Appendix C. | |||
A.1. The User Composes an Email | A.1. The User Composes an Email | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <;20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
Figure 1: The User Composes an Email | Figure 1: The User Composes an Email | |||
A.2. The Email is Signed | A.2. The Email is Signed | |||
End of changes. 33 change blocks. | ||||
61 lines changed or deleted | 65 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/ |