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/