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/