draft-ietf-dkim-rfc4871bis-07.txt | draft-ietf-dkim-rfc4871bis-08.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: October 26, 2011 Cloudmark | Expires: October 29, 2011 Cloudmark | |||
April 24, 2011 | April 27, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-07 | draft-ietf-dkim-rfc4871bis-08 | |||
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 October 26, 2011. | This Internet-Draft will expire on October 29, 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 44 | skipping to change at page 2, line 44 | |||
3.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | 3.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | |||
3.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 | 3.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 | |||
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 | 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 | 4.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 | |||
4.3. Signing and Verification Algorithms . . . . . . . . . . . 14 | 4.3. Signing and Verification Algorithms . . . . . . . . . . . 14 | |||
4.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | 4.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 20 | 4.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 20 | |||
4.6. Key Management and Representation . . . . . . . . . . . . 29 | 4.6. Key Management and Representation . . . . . . . . . . . . 29 | |||
4.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | 4.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | |||
4.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 36 | 4.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | |||
4.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 | 4.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 | |||
4.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 | 4.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 | |||
5. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 | 5. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 | |||
5.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | 5.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | |||
5.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | 5.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | |||
6. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | 6. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
6.1. Determine Whether the Email Should Be Signed and by | 6.1. Determine Whether the Email Should Be Signed and by | |||
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
6.2. Select a Private Key and Corresponding Selector | 6.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 40 | Information . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
6.3. Normalize the Message to Prevent Transport Conversions . . 41 | 6.3. Normalize the Message to Prevent Transport Conversions . . 40 | |||
6.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | 6.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | |||
6.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | 6.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | |||
6.6. Compute the Message Hash and Signature . . . . . . . . . . 45 | 6.6. Compute the Message Hash and Signature . . . . . . . . . . 45 | |||
6.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | 6.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | |||
7. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 | 7. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
7.1. Extract Signatures from the Message . . . . . . . . . . . 46 | 7.1. Extract Signatures from the Message . . . . . . . . . . . 46 | |||
7.2. Communicate Verification Results . . . . . . . . . . . . . 52 | 7.2. Communicate Verification Results . . . . . . . . . . . . . 51 | |||
7.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | 7.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
8.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | 8.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | |||
8.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | 8.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | |||
8.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | 8.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | |||
8.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | 8.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | |||
8.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | 8.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | |||
8.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | 8.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | |||
8.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | 8.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | |||
8.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | 8.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | |||
skipping to change at page 5, line 8 | skipping to change at page 5, line 8 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | |||
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 | |||
1. Notes to Editor and Reviewers | 1. Notes to Editor and Reviewers | |||
This version of the memo contains notations such as "{DKIM 2}". | This version of the memo contains notations such as "{DKIM 2}". | |||
These correspond to DKIM working group issue tracker items. they | These correspond to DKIM working group issue tracker items. They | |||
should be deleted prior to publication. | should be deleted prior to publication. | |||
2. Introduction | 2. 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 | |||
skipping to change at page 8, line 12 | skipping to change at page 8, line 12 | |||
handling path, an independent trust assessment service, and a mailing | handling path, an independent trust assessment service, and a mailing | |||
list operator. | list operator. | |||
3.4. Identifier | 3.4. Identifier | |||
A label that refers to an identity. | A label that refers to an identity. | |||
3.5. Signing Domain Identifier (SDID) | 3.5. Signing Domain Identifier (SDID) | |||
A single domain name that is the mandatory payload output of DKIM and | A single domain name that is the mandatory payload output of DKIM and | |||
that refers to the identity claiming responsibility for introduction | that refers to the identity claiming some responsibility for the | |||
of a message into the mail stream. For DKIM processing, the name has | message by signing it. It is specified in Section 4.5. | |||
only basic domain name semantics; any possible owner-specific | ||||
semantics are outside the scope of DKIM. It is specified in | ||||
Section 4.5. | ||||
3.6. Agent or User Identifier (AUID) | 3.6. Agent or User Identifier (AUID) | |||
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 | |||
skipping to change at page 14, line 19 | skipping to change at page 14, line 19 | |||
empty value explicitly designates the empty string as the value. | empty value explicitly designates the empty string as the value. | |||
4.3. Signing and Verification Algorithms | 4.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 rsa-sha256. | |||
INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some | INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some | |||
senders of low-security messages (such as routine newsletters) may | senders might prefer to use rsa-sha1 when balancing security | |||
prefer to use rsa-sha1 because of reduced CPU requirements to | strength against performance, complexity, or other needs. | |||
compute a SHA1 hash. MTAs with compliant verifierst that do not | However, compliant verifiers might not implement rsa-sha1; they | |||
implement rsa-sha1 will treat such messages as unsigned. {DKIM 13} | will treat such messages as unsigned. {DKIM 13} | |||
In general, rsa-sha256 should always be used whenever possible. | ||||
4.3.1. The rsa-sha1 Signing Algorithm | 4.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 4.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. | in Section 4.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 23, line 5 | skipping to change at page 22, line 35 | |||
d= The SDID claiming responsibility for an introduction of a message | d= The SDID claiming responsibility for an introduction of a message | |||
into the mail stream (plain-text; REQUIRED). Hence, the SDID | into the mail stream (plain-text; REQUIRED). Hence, the SDID | |||
value is used to form the query for the public key. The SDID MUST | value is used to form the query for the public key. The SDID MUST | |||
correspond to a valid DNS name under which the DKIM key record is | correspond to a valid DNS name under which the DKIM key record is | |||
published. The conventions and semantics used by a signer to | published. The conventions and semantics used by a signer to | |||
create and use a specific SDID are outside the scope of the DKIM | create and use a specific SDID are outside the scope of the DKIM | |||
Signing specification, as is any use of those conventions and | Signing specification, as is any use of those conventions and | |||
semantics. When presented with a signature that does not meet | semantics. When presented with a signature that does not meet | |||
these requirements, verifiers MUST consider the signature invalid. | these requirements, verifiers MUST consider the signature invalid. | |||
Internationalized domain names MUST be encoded as described in | Internationalized domain names MUST be encoded as A-Labels, as | |||
Section 2.3 of [RFC5890] to "A-Labels". {DKIM 4}. | described in Section 2.3 of [RFC5890]. {DKIM 4}. | |||
ABNF: | ABNF: | |||
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | |||
domain-name = sub-domain 1*("." sub-domain) | domain-name = sub-domain 1*("." sub-domain) | |||
; from RFC5321 Domain, excluding address-literal | ; from RFC5321 Domain, excluding address-literal | |||
h= Signed header fields (plain-text, but see description; REQUIRED). | h= Signed header fields (plain-text, but see description; REQUIRED). | |||
A colon-separated list of header field names that identify the | A colon-separated list of header field names that identify the | |||
header fields presented to the signing algorithm. The field MUST | header fields presented to the signing algorithm. The field MUST | |||
skipping to change at page 24, line 19 | skipping to change at page 24, line 14 | |||
i= The Agent or User Identifier (AUID) on behalf of which the SDID is | i= The Agent or User Identifier (AUID) on behalf of which the SDID is | |||
taking responsibility (dkim-quoted-printable; OPTIONAL, default is | taking responsibility (dkim-quoted-printable; OPTIONAL, default is | |||
an empty Local-part followed by an "@" followed by the domain from | an empty Local-part followed by an "@" followed by the domain from | |||
the "d=" tag). | the "d=" tag). | |||
The syntax is a standard email address where the Local-part MAY be | The syntax is a standard email address where the Local-part MAY be | |||
omitted. The domain part of the address MUST be the same as, or a | omitted. The domain part of the address MUST be the same as, or a | |||
subdomain of, the value of the "d=" tag. | subdomain of, the value of the "d=" tag. | |||
Internationalized domain names MUST be converted as described in | Internationalized domain names MUST be encoded as A-Labels, as | |||
Section 2.3 of [RFC5890] to "A-Labels" {DKIM 4}. | described in Section 2.3 of [RFC5890]. {DKIM 4}. | |||
ABNF: | ABNF: | |||
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] | sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] | |||
"@" domain-name | "@" domain-name | |||
The AUID is specified as having the same syntax as an email | The AUID is specified as having the same syntax as an email | |||
address, but is not required to have the same semantics. Notably, | address, but is not required to have the same semantics. Notably, | |||
the domain name is not required to be registered in the DNS -- so | the domain name is not required to be registered in the DNS -- so | |||
it might not resolve in a query -- and the Local-part MAY be drawn | it might not resolve in a query -- and the Local-part MAY be drawn | |||
skipping to change at page 27, line 4 | skipping to change at page 26, line 35 | |||
"txt", which MUST be included. Verifiers and signers MUST support | "txt", which MUST be included. Verifiers and signers MUST support | |||
"dns/txt". | "dns/txt". | |||
ABNF: | ABNF: | |||
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method | |||
*([FWS] ":" [FWS] sig-q-tag-method) | *([FWS] ":" [FWS] sig-q-tag-method) | |||
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type | sig-q-tag-method = "dns/txt" / x-sig-q-tag-type | |||
["/" x-sig-q-tag-args] | ["/" x-sig-q-tag-args] | |||
x-sig-q-tag-type = hyphenated-word ; for future extension | x-sig-q-tag-type = hyphenated-word ; for future extension | |||
x-sig-q-tag-args = qp-hdr-value | x-sig-q-tag-args = qp-hdr-value | |||
s= The selector subdividing the namespace for the "d=" (domain) tag | s= The selector subdividing the namespace for the "d=" (domain) tag | |||
(plain-text; REQUIRED). | (plain-text; REQUIRED). | |||
Internationalized selector names MUST be encoded as A-Labels, as | ||||
described in Section 2.3 of [RFC5890]. {DKIM 4}. | ||||
ABNF: | ABNF: | |||
sig-s-tag = %x73 [FWS] "=" [FWS] selector | sig-s-tag = %x73 [FWS] "=" [FWS] selector | |||
t= Signature Timestamp (plain-text unsigned decimal integer; | t= Signature Timestamp (plain-text unsigned decimal integer; | |||
RECOMMENDED, default is an unknown creation time). The time that | RECOMMENDED, default is an unknown creation time). The time that | |||
this signature was created. The format is the number of seconds | this signature was created. The format is the number of seconds | |||
since 00:00:00 on January 1, 1970 in the UTC time zone. The value | since 00:00:00 on January 1, 1970 in the UTC time zone. The value | |||
is expressed as an unsigned integer in decimal ASCII. This value | is expressed as an unsigned integer in decimal ASCII. This value | |||
is not constrained to fit into a 31- or 32-bit integer. | is not constrained to fit into a 31- or 32-bit integer. | |||
Implementations SHOULD be prepared to handle values up to at least | Implementations SHOULD be prepared to handle values up to at least | |||
skipping to change at page 43, line 39 | skipping to change at page 43, line 23 | |||
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | |||
specification, all end-user visible header fields should be signed | specification, all end-user visible header fields should be signed | |||
to avoid possible "indirect spamming". For example, if the | to avoid possible "indirect spamming". For example, if the | |||
Subject header field is not signed, a spammer can resend a | Subject header field is not signed, a spammer can resend a | |||
previously signed mail, replacing the legitimate subject with a | previously signed mail, replacing the legitimate subject with a | |||
one-line spam. | one-line spam. | |||
6.5. Recommended Signature Content | 6.5. Recommended Signature Content | |||
In order to maximize compatibility with a variety of verifiers, it is | {DKIM 20} | |||
recommended that signers follow the practices outlined in this | ||||
section when signing a message. However, these are generic | ||||
recommendations applying to the general case; specific senders may | ||||
wish to modify these guidelines as required by their unique | ||||
situations. Verifiers MUST be capable of verifying signatures even | ||||
if one or more of the recommended header fields is not signed (with | ||||
the exception of From, which must always be signed) or if one or more | ||||
of the dis-recommended header fields is signed. Note that verifiers | ||||
do have the option of ignoring signatures that do not cover a | ||||
sufficient portion of the header or body, just as they may ignore | ||||
signatures from an identity they do not trust. | ||||
The following header fields SHOULD be included in the signature, if | ||||
they are present in the message being signed: | ||||
o From (REQUIRED in all signatures) | The purpose of the DKIM cryptographic algorithm is to affix an | |||
identifier to the message in a way that is both robust against normal | ||||
transit-related changes and resistant to kinds of replay attacks. An | ||||
essential aspect of satisfying these requirements is choosing what | ||||
header fields to include in the hash and what fields to exclude. | ||||
o Sender, Reply-To | The basic rule for choosing fields to include is to select those | |||
fields that constitute the "core" of the message content. Hence, any | ||||
replay attack will have to include these in order to have the | ||||
signature succeed; but with these included, the core of the message | ||||
is valid, even if sent on to new recipients. | ||||
o Subject | Common examples of fields with addresses and fields with textual | |||
content related to the body are: | ||||
o Date, Message-ID | o From (REQUIRED; see Section 6.4) | |||
o To, Cc | o Reply-To | |||
o MIME-Version | o Subject | |||
o Content-Type, Content-Transfer-Encoding, Content-ID, Content- | o Date | |||
Description | ||||
o Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, | o To, Cc | |||
Resent-Message-ID | ||||
o Resent-Date, Resent-From, Resent-To, Resent-Cc | ||||
o In-Reply-To, References | o In-Reply-To, References | |||
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, | o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, | |||
List-Owner, List-Archive | List-Owner, List-Archive | |||
The following header fields SHOULD NOT be included in the signature: | If the "l=" signature tag is in use (see Section 4.5), the Content- | |||
Type field is also a candidate for being included as it could be | ||||
replaced in a way that causes completely different content to be | ||||
rendered to the receiving user. | ||||
Another class of fields that may be of interest are those that convey | ||||
security-related information about the message, such as | ||||
Authentication-Results [RFC5451]. | ||||
The basic rule for choosing field to exclude is to select those | ||||
fields for which there are multiple fields with the same name, and | ||||
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 | |||
o Bcc, Resent-Bcc | Note that the DKIM-Signature field is also excluded from the header | |||
hash, because its handling is specified separately. | ||||
o DKIM-Signature | ||||
Optional header fields (those not mentioned above) normally SHOULD | Typically, it is better to exclude other, optional fields because of | |||
NOT be included in the signature, because of the potential for | the potential that additional fields of the same name will be | |||
additional header fields of the same name to be legitimately added or | legitimately added or re-ordered prior to verification. There are | |||
reordered prior to verification. There are likely to be legitimate | likely to be legitimate exceptions to this rule, because of the wide | |||
exceptions to this rule, because of the wide variety of application- | variety of application-specific header fields that might be applied | |||
specific header fields that may be applied to a message, some of | to a message, some of which are unlikely to be duplicated, modified, | |||
which are unlikely to be duplicated, modified, or reordered. | or reordered. | |||
Signers SHOULD choose canonicalization algorithms based on the types | Signers SHOULD choose canonicalization algorithms based on the types | |||
of messages they process and their aversion to risk. For example, | of messages they process and their aversion to risk. For example, | |||
e-commerce sites sending primarily purchase receipts, which are not | e-commerce sites sending primarily purchase receipts, which are not | |||
expected to be processed by mailing lists or other software likely to | expected to be processed by mailing lists or other software likely to | |||
modify messages, will generally prefer "simple" canonicalization. | modify messages, will generally prefer "simple" canonicalization. | |||
Sites sending primarily person-to-person email will likely prefer to | Sites sending primarily person-to-person email will likely prefer to | |||
be more resilient to modification during transport by using "relaxed" | be more resilient to modification during transport by using "relaxed" | |||
canonicalization. | canonicalization. | |||
skipping to change at page 63, line 7 | skipping to change at page 63, line 7 | |||
Many email implementations do not enforce [RFC5322] with strictness. | Many email implementations do not enforce [RFC5322] with strictness. | |||
As discussed in Section 6.3 DKIM processing is predicated on a valid | As discussed in Section 6.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 last, or "top", From: field. This may also be done | value of the first {DKIM 16}, or "top", From: field. This may also | |||
simply out of the expectation that there is only one, where a "find | be done simply out of the expectation that there is only one, where a | |||
first" algorithm would have the same result. Such code in an MUA can | "find first" algorithm would have the same result. Such code in an | |||
be exploited to fool the user if it is also known that the other | MUA can be exploited to fool the user if it is also known that the | |||
From: field is the one checked by arriving message filters. Such is | other From: field is the one checked by arriving message filters. | |||
the case with DKIM; although the From: field must be signed, a | Such is the case with DKIM; although the From: field must be signed, | |||
malformed message bearing more than one From: field might only have | a malformed message bearing more than one From: field might only have | |||
the first ("bottom") one signed, in an attempt to show the message | the first ("bottom") one signed, in an attempt to show the message | |||
with some "DKIM passed" annotation while also rendering the From: | with some "DKIM passed" annotation while also rendering the From: | |||
field that was not authenticated. (This can also be taken as a | field that was not authenticated. (This can also be taken as a | |||
demonstration that DKIM is not designed to support author | demonstration that DKIM is not designed to support author | |||
validation.) | validation.) | |||
To resist this specific attack the signed header field list can | Note that the technique for using "h=...:from:from:...", described in | |||
include an additional reference for each field that was present at | Section 9.15 below, is of no effect in the case of an attacker that | |||
signing. For example, a proper message with one From: field could be | is also the signer. {DKIM 16} | |||
signed using "h=From:From:..." Due to the way header fields are | ||||
canonicalized for input to the hash function, the extra field | ||||
references will prevent instances of the cited fields from being | ||||
added after signing, as doing so would render the signature invalid. | ||||
The From: field is used above to illustrate this issue, but it is | The From: field is used above to illustrate this issue, but it is | |||
only one of several fields that Section 3.6 of [RFC5322] constrains | only one of several fields that Section 3.6 of [RFC5322] constrains | |||
in this way. In reality any agent that forgives malformations, or is | in this way. In reality any agent that forgives such malformations | |||
careless about identifying which parts of a message were | {DKIM 16}, or is careless about identifying which parts of a message | |||
authenticated, is open to exploitation. | were authenticated, is open to exploitation. | |||
9.15. Malformed Inputs | 9.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. The attack is accomplished by creating | example in a replay attack or a man-in-the-middle attack {DKIM 16}. | |||
additional instances of header fields to an already signed message, | The attack is accomplished by creating additional instances of header | |||
without breaking the signature. These then might be displayed to the | fields to an already signed message, without breaking the signature. | |||
end user or are used as filtering input. Salient fields could | These then might be displayed to the end user or are used as | |||
include From: and Subject:, | filtering input. Salient fields could 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 in some cases it might display the newly added header fields | but it will commonly {DKIM 16} display the newly added header fields | |||
rather than those that are part of the originally signed message | rather than those that are part of the originally signed message | |||
alongside some "valid DKIM signature" annotation. This might allow | alongside some "valid DKIM signature" annotation. This might allow | |||
an attacker to replay a previously sent, signed message with a | an attacker to replay a previously sent, signed message with a | |||
different Subject:, From: or To: field. | different Subject:, From: or To: field. | |||
However, [RFC5322] also tolerates obsolete message syntax, which does | However, [RFC5322] also tolerates obsolete message syntax, which does | |||
allow things like multiple From: fields on messages. The | allow things like multiple From: fields on messages. The | |||
implementation of DKIM thus potentially creates a more stringent | implementation of DKIM thus potentially creates a more stringent | |||
layer of expectation regarding the meaning of an identity, while that | layer of expectation regarding the meaning of an identity, while that | |||
additional meaning is either obscured from or incorrectly presented | additional meaning is either obscured from or incorrectly presented | |||
to an end user in this context. | to an end user in this context. | |||
Implementers need to consider this possibility when designing their | Implementers need to consider this possibility when designing their | |||
input handling functions. Outright rejection of messages that | input handling functions. Outright rejection of messages that | |||
violate Section 3.6 of [RFC5322] will interfere with delivery of | violate the relevant standards such as [RFC5322], [RFC2045], etc. | |||
legacy formats. Instead, given such input, a signing module could | will interfere with delivery of {DKIM 16} legacy formats. Instead, | |||
return an error rather than generate a signature; a verifying module | given such input, a signing module could return an error rather than | |||
might return a syntax error code or arrange not to return a positive | generate a signature; a verifying module might return a syntax error | |||
result even if the signature technically validates. | code or arrange not to return a positive result even if the signature | |||
technically validates. | ||||
Senders concerned that their messages might be particularly | Senders concerned that their messages might be particularly | |||
vulnerable to this sort of attack and who do not wish to rely on | vulnerable to this sort of attack and who do not wish to rely on | |||
receiver filtering of invalid messages can ensure that adding | receiver filtering of invalid messages can ensure that adding | |||
additional header fields will break the DKIM signature by including | additional header fields will break the DKIM signature by including | |||
two copies of the header fields about which they are concerned in the | two copies of the header fields about which they are concerned in the | |||
signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | |||
Sections 3.5 and 5.4 for further discussion of this mechanism. | Sections 3.5 and 5.4 for further discussion of this mechanism. | |||
Specific validity rules for all known header fields can be gleaned | Specific validity rules for all known header fields can be gleaned | |||
skipping to change at page 74, line 19 | skipping to change at page 74, line 19 | |||
similar to this: | similar to this: | |||
-----BEGIN PUBLIC KEY----- | -----BEGIN PUBLIC KEY----- | |||
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM | MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM | |||
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R | oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R | |||
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI | tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI | |||
MmPSPDdQPNUYckcQ2QIDAQAB | MmPSPDdQPNUYckcQ2QIDAQAB | |||
-----END PUBLIC KEY----- | -----END PUBLIC KEY----- | |||
This public-key data (without the BEGIN and END tags) is placed in | This public-key data (without the BEGIN and END tags) is placed in | |||
the DNS: | the DNS: | |||
$ORIGIN _domainkey.example.org. {DKIM 10} | ||||
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | |||
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | |||
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | |||
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | |||
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | |||
C.1. Compatibility with DomainKeys Key Records | C.1. Compatibility with DomainKeys Key Records | |||
DKIM key records were designed to be backwards-compatible in many | DKIM key records were designed to be backwards-compatible in many | |||
cases with key records used by DomainKeys [RFC4870] (sometimes | cases with key records used by DomainKeys [RFC4870] (sometimes | |||
End of changes. 34 change blocks. | ||||
87 lines changed or deleted | 89 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/ |