--- 1/draft-ietf-dkim-rfc4871bis-01.txt 2010-10-11 23:14:05.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-02.txt 2010-10-11 23:14:05.000000000 +0200 @@ -1,21 +1,21 @@ DKIM D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871 (if approved) T. Hansen, Ed. Intended status: Standards Track AT&T Laboratories -Expires: March 31, 2011 M. Kucherawy, Ed. +Expires: April 14, 2011 M. Kucherawy, Ed. Cloudmark - September 27, 2010 + October 11, 2010 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-01 + draft-ietf-dkim-rfc4871bis-02 Abstract DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 31, 2011. + This Internet-Draft will expire on April 14, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,95 +79,95 @@ 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 3.6. Key Management and Representation . . . . . . . . . . . . 28 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 36 - 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37 - 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38 + 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 + 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1. Determine Whether the Email Should Be Signed and by - Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Select a Private Key and Corresponding Selector Information . . . . . . . . . . . . . . . . . . . . . . . 39 - 5.3. Normalize the Message to Prevent Transport Conversions . . 39 + 5.3. Normalize the Message to Prevent Transport Conversions . . 40 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 40 5.5. Recommended Signature Content . . . . . . . . . . . . . . 42 - 5.6. Compute the Message Hash and Signature . . . . . . . . . . 43 + 5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 44 - 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44 + 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 6.1. Extract Signatures from the Message . . . . . . . . . . . 45 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 - 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 - 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52 + 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 + 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 53 - 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53 + 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 - 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55 - 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55 + 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 + 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 - 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 - 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56 - 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57 - 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 - 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58 - 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 + 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 + 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 + 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 + 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 + 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 + 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 - 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 - 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60 - 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60 - 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60 + 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 + 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 + 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 + 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 - 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 61 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 62 - Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 63 - A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 - A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64 - A.3. The Email Signature is Verified . . . . . . . . . . . . . 65 - Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66 - B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 66 - B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 68 - Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 70 - Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 71 - Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72 - Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 73 - F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 73 - F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 - - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 + 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 + 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 + Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 + A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65 + A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65 + A.3. The Email Signature is Verified . . . . . . . . . . . . . 66 + Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67 + B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 + B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 + Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 + Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 73 + Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 + Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 74 + F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 74 + F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 1. Introduction DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message. The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions - (S/MIME) [RFC1847], OpenPGP [RFC2440]) in that: + (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: o the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body; o there is no dependency on public and private key pairs being issued by well-known, trusted certificate authorities; o there is no dependency on the deployment of any new Internet @@ -313,43 +313,43 @@ o FWS is folding whitespace. It allows multiple lines separated by CRLF followed by at least one whitespace, to be joined. The formal ABNF for these are (WSP and LWSP are given for information only): WSP = SP / HTAB LWSP = *(WSP / CRLF WSP) FWS = [*WSP CRLF] 1*WSP - The definition of FWS is identical to that in [RFC2822] except for + The definition of FWS is identical to that in [RFC5322] except for the exclusion of obs-FWS. 2.9. Common ABNF Tokens The following ABNF tokens are used elsewhere in this document: hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) [ [FWS] "=" [ [FWS] "=" ] ] 2.10. Imported ABNF Tokens The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive. - The following tokens are imported from [RFC2821]: + The following tokens are imported from [RFC5321]: o "Local-part" (implementation warning: this permits quoted strings) o "sub-domain" - The following tokens are imported from [RFC2822]: + The following tokens are imported from [RFC5322]: o "field-name" (name of a header field) o "dot-atom-text" (in the Local-part of an email address) The following tokens are imported from [RFC2045]: o "qp-section" (a single line of quoted-printable-encoded text) o "hex-octet" (a quoted-printable encoded octet) @@ -371,26 +371,27 @@ the hexadecimal-encoded integer value of that character. All control characters (those with values < %x20), 8-bit characters (values > %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon (";", %x3B) MUST be encoded. Note that all whitespace, including SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value, and MUST be removed before decoding. ABNF: + dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) ; hex-octet is from RFC2045 dkim-safe-char = %x21-3A / %x3C / %x3E-7E ; '!' - ':', '<', '>' - '~' ; Characters not listed as "mail-safe" in - ; RFC2049 are also not recommended. + ; [RFC2049] are also not recommended. INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- Printable as defined in [RFC2045] in several important ways: 1. Whitespace in the input text, including CR and LF, must be encoded. [RFC2045] does not require such encoding, and does not permit encoding of CR or LF characters that are part of a CRLF line break. 2. Whitespace in the encoded text is ignored. This is to allow @@ -503,21 +504,21 @@ The name of the tag will determine the encoding of each value. Unencoded semicolon (";") characters MUST NOT occur in the tag value, since that separates tag-specs. INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined below (as "tag-value") only includes 7-bit characters, an implementation that wished to anticipate future standards would be advised not to preclude the use of UTF8-encoded text in tag=value lists. - Formally, the syntax rules are as follows: + Formally, the ABNF syntax rules are as follows: tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] tag-name = ALPHA 0*ALNUMPUNC tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] ; WSP and FWS prohibited at beginning and end tval = 1*VALCHAR VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON ALNUMPUNC = ALPHA / DIGIT / "_" @@ -619,21 +620,21 @@ immaterial to validation of the DKIM domain name's use. For such signers, a canonicalization algorithm that survives modest in-transit modification is preferred. Other signers demand that any modification of the email, however minor, result in a signature verification failure. These signers prefer a canonicalization algorithm that does not tolerate in-transit modification of the signed email. Some signers may be willing to accept modifications to header fields - that are within the bounds of email standards such as [RFC2822], but + that are within the bounds of email standards such as [RFC5322], but are unwilling to accept any modification to the body of messages. To satisfy all requirements, two canonicalization algorithms are defined for each of the header and the body: a "simple" algorithm that tolerates almost no modification and a "relaxed" algorithm that tolerates common modifications such as whitespace replacement and header field line rewrapping. A signer MAY specify either algorithm for header or body when signing an email. If no canonicalization algorithm is specified by the signer, the "simple" algorithm defaults for both header and body. Verifiers MUST implement both @@ -662,21 +663,21 @@ 3.4.2. The "relaxed" Header Canonicalization Algorithm The "relaxed" header canonicalization algorithm MUST apply the following steps in order: o Convert all header field names (not the header field values) to lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". o Unfold all header field continuation lines as described in - [RFC2822]; in particular, lines with terminators embedded in + [RFC5322]; in particular, lines with terminators embedded in continued header field values (that is, CRLF sequences followed by WSP) MUST be interpreted without the CRLF. Implementations MUST NOT remove the CRLF at the end of the header field value. o Convert all sequences of one or more WSP characters to a single SP character. WSP characters here include those before and after a line folding boundary. o Delete all WSP characters at the end of each unfolded header field value. @@ -835,21 +836,21 @@ D E 3.5. The DKIM-Signature Header Field The signature of the email is stored in the DKIM-Signature header field. This header field contains all of the signature and key- fetching data. The DKIM-Signature value is a tag-list as described in Section 3.2. The DKIM-Signature header field SHOULD be treated as though it were a - trace header field as defined in Section 3.6 of [RFC2822], and hence + trace header field as defined in Section 3.6 of [RFC5322], and hence SHOULD NOT be reordered and SHOULD be prepended to the message. The DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the "b=" tag (signature value) of that DKIM- Signature header field MUST be treated as though it were an empty string. Unknown tags in the DKIM-Signature header field MUST be included in the signature calculation but MUST be otherwise ignored by verifiers. Other DKIM-Signature header fields that are included @@ -936,23 +937,24 @@ record is published. The conventions and semantics used by a signer to create and use a specific SDID are outside the scope of the DKIM Signing specification, as is any use of those conventions and semantics. When presented with a signature that does not meet these requirements, verifiers MUST consider the signature invalid. Internationalized domain names MUST be encoded as described in [RFC3490]. ABNF: + sig-d-tag = %x64 [FWS] "=" [FWS] domain-name - domain-name = sub-domain 1*("." sub-domain) ; from - RFC 5321 Domain, but excluding address-literall +domain-name = sub-domain 1*("." sub-domain) + ; from RFC 5321 Domain, but excluding address-literall h= Signed header fields (plain-text, but see description; REQUIRED). A colon-separated list of header field names that identify the header fields presented to the signing algorithm. The field MUST contain the complete list of header fields in the order presented to the signing algorithm. The field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF @@ -1158,26 +1161,26 @@ ("|", %x7C) character (i.e., vertical bars in the "z=" text are meta-characters, and any actual vertical bar characters in a copied header field must be encoded). Note that all whitespace must be encoded, including whitespace between the colon and the header field value. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field, and MUST be removed before decoding. The header fields referenced by the "h=" tag refer to the fields - in the [RFC2822] header of the message, not to any copied fields + in the [RFC5322] header of the message, not to any copied fields in the "z=" tag. Copied header field values are for diagnostic use. Header fields with characters requiring conversion (perhaps from - legacy MTAs that are not [RFC2822] compliant) SHOULD be converted + legacy MTAs that are not [RFC5322] compliant) SHOULD be converted as described in MIME Part Three [RFC2047]. ABNF: sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy *( "|" [FWS] sig-z-tag-copy ) sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value INFORMATIVE EXAMPLE of a signature header field spread across multiple continuation lines: DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; @@ -1446,21 +1450,21 @@ MUST NOT be included in its own h= tag, although other DKIM-Signature header fields MAY be signed (see Section 4). When calculating the hash on messages that will be transmitted using base64 or quoted-printable encoding, signers MUST compute the hash after the encoding. Likewise, the verifier MUST incorporate the values into the hash before decoding the base64 or quoted-printable text. However, the hash MUST be computed before transport level encodings such as SMTP "dot-stuffing" (the modification of lines beginning with a "." to avoid confusion with the SMTP end-of-message - marker, as specified in [RFC2821]). + marker, as specified in [RFC5321]). With the exception of the canonicalization procedure described in Section 3.4, the DKIM signing process treats the body of messages as simply a string of octets. DKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content. Message attachments in MIME format MUST be included in the content that is signed. More formally, the algorithm for the signature is as follows: body-hash = hash-alg(canon_body) @@ -1709,39 +1713,45 @@ Some messages, particularly those using 8-bit characters, are subject to modification during transit, notably conversion to 7-bit form. Such conversions will break DKIM signatures. In order to minimize the chances of such breakage, signers SHOULD convert the message to a suitable MIME content transfer encoding such as quoted-printable or base64 as described in [RFC2045] before signing. Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm. + Similarly, a message that is not compliant with RFC5322, RFC2045 + correct or interpret such content. See Section 8 of [RFC4409] for + examples of changes that are commonly made. Such "corrections" may + break DKIM signatures or have other undesirable effects. Therefore, + a verifier SHOULD NOT validate a message that is not conformant. + If the message is submitted to the signer with any local encoding that will be modified before transmission, that modification to - canonical [RFC2822] form MUST be done before signing. In particular, + canonical [RFC5322] form MUST be done before signing. In particular, bare CR or LF characters (used by some systems as a local line separator convention) MUST be converted to the SMTP-standard CRLF sequence before the message is signed. Any conversion of this sort SHOULD be applied to the message actually sent to the recipient(s), not just to the version presented to the signing algorithm. More generally, the signer MUST sign the message as it is expected to be received by the verifier rather than in some local or internal form. 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field). Signers SHOULD NOT sign an existing header field likely to be legitimately modified - or removed in transit. In particular, [RFC2821] explicitly permits + or removed in transit. In particular, [RFC5321] explicitly permits modification or removal of the Return-Path header field in transit. Signers MAY include any other header fields present at the time of signing at the discretion of the signer. INFORMATIVE OPERATIONS NOTE: The choice of which header fields to sign is non-obvious. One strategy is to sign all existing, non- repeatable header fields. An alternative strategy is to sign only header fields that are likely to be displayed to or otherwise be likely to affect the processing of the message at the receiver. A third strategy is to sign only "well known" headers. Note that @@ -1798,26 +1808,26 @@ then the resulting DKIM-Signature header field should read: DKIM-Signature: ... h=Received : Received :... and Received header fields and will be signed in that order. Signers should be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or otherwise reordered. Trace header fields (such as Received) and - Resent-* blocks are the only fields prohibited by [RFC2822] from + Resent-* blocks are the only fields prohibited by [RFC5322] from being reordered. In particular, since DKIM-Signature header fields may be reordered by some intermediate MTAs, signing existing DKIM- Signature header fields is error-prone. - INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits + INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits header fields to be reordered (with the exception of Received header fields), reordering of signed header fields with multiple instances by intermediate MTAs will cause DKIM signatures to be broken; such anti-social behavior should be avoided. INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this specification, all end-user visible header fields should be signed to avoid possible "indirect spamming". For example, if the Subject header field is not signed, a spammer can resend a previously signed mail, replacing the legitimate subject with a @@ -2240,21 +2250,21 @@ displayed to the end user. 6.2. Communicate Verification Results Verifiers wishing to communicate the results of verification to other parts of the mail system may do so in whatever manner they see fit. For example, implementations might choose to add an email header field to the message before passing it on. Any such header field SHOULD be inserted before any existing DKIM-Signature or preexisting authentication status header fields in the header field block. The - Authentication-Results: header ([RFC5451]) MAY be used for this + Authentication-Results: header field ([RFC5451]) MAY be used for this purpose. INFORMATIVE ADVICE to MUA filter writers: Patterns intended to search for results header fields to visibly mark authenticated mail for end users should verify that such header field was added by the appropriate verifying domain and that the verified identity matches the author identity that will be displayed by the MUA. In particular, MUA filters should not be influenced by bogus results header fields added by attackers. To circumvent this attack, verifiers may wish to delete existing results header fields after @@ -2311,21 +2321,21 @@ diagnostic purposes, the exact reason why the verification fails SHOULD be made available to the policy module and possibly recorded in the system logs. If the email cannot be verified, then it SHOULD be rendered the same as all unverified email regardless of whether or not it looks like it was signed. 7. IANA Considerations DKIM has registered new namespaces with IANA. In all cases, new values are assigned only for values that have been documented in a - published RFC that has IETF Consensus [RFC2434]. + published RFC that has IETF Consensus [RFC5226]. 7.1. DKIM-Signature Tag Specifications A DKIM-Signature provides for a list of tag specifications. IANA has established the DKIM-Signature Tag Specification Registry for tag specifications that can be used in DKIM-Signature fields. The initial entries in the registry comprise: +------+-----------------+ @@ -2541,24 +2551,23 @@ 8.1.2. Addition of new HTML content to existing content Several receiving MUA implementations do not cease display after a """" tag. In particular, this allows attacks involving overlaying images on top of existing text. INFORMATIVE EXAMPLE: Appending the following text to an existing, properly closed message will in many MUAs result in inappropriate data being rendered on top of existing, correct data: -
+ +
+
8.2. Misappropriated Private Key If the private key for a user is resident on their computer and is not protected by an appropriately secure mechanism, it is possible for malware to send mail as that user and any other user sharing the same private key. The malware would not, however, be able to generate signed spoofs of other signers' addresses, which would aid in identification of the infected user and would limit the possibilities for certain types of attacks involving socially @@ -2616,21 +2625,21 @@ Since the DNS is a required binding for key services, specific attacks against the DNS must be considered. While the DNS is currently insecure [RFC3833], these security problems are the motivation behind DNS Security (DNSSEC) [RFC4033], and all users of the DNS will reap the benefit of that work. DKIM is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as - OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. + OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements. A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching selector-based data as well as fetching signing domain policy. Widespread deployment of DKIM will result in a significant increase in DNS queries to the claimed signing domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries. A specific DNS security issue that should be considered by DKIM verifiers is the name chaining attack described in Section 2.3 of @@ -2744,20 +2753,53 @@ domain. INFORMATIVE NOTE: This is considered an acceptable risk for the same reason that it is acceptable for domain delegation. For example, in the example above any of the domains could potentially simply delegate "example.podunk.ca.us" to a server of their choice and completely replace all DNS-served information. Note that a verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1. +8.14. Attacks Involving Addition of Header Fields + + Many email implementations do not enforce [RFC5322] with strictness. + As discussed in Section 5.3 DKIM processing is predicated on a valid + mail message as its input. However, DKIM implementers should be + aware of the potential effect of having loose enforcement by email + components interacting with DKIM modules. + + For example, a message with multiple From: header fields violates + Section 3.6 of [RFC5322]. With the intent of providing a better user + experience, many agents tolerate these violations and deliver the + message anyway. An MUA then might elect to render to the user the + value of the last, or "top", From: field. This may also be done + simply out of the expectation that there is only one, where a "find + first" algorithm would have the same result. Such code in an MUA can + be exploited to fool the user if it is also known that the other + From: field is the one checked by arriving message filters. Such is + the case with DKIM; although the From: field must be signed, a + malformed message bearing more than one From: field might only have + the first ("bottom") one signed, in an attempt to show the message + with some "DKIM passed" annotation while also rendering the From: + field that was not authenticated. (This can also be taken as a + demonstration that DKIM is not designed to support author + validation.) + + A signer wishing to be resistant to this specific attack can include + in the signed header field list an additional instance of each field + that was present at signing. For example, a proper message with one + From: field could be signed using "h=From:From:..." Because of the + way header fields are canonicalized for input to the hash function, + this would prevent additional fields from being added, after signing, + as this would render the signature invalid. + 9. References 9.1. Normative References [FIPS-180-2-2002] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-2, August 2002. [ITU-X660-1997] "Information Technology - ASN.1 encoding rules: @@ -2773,89 +2815,92 @@ Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, - April 2001. - - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, - April 2001. - [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, + October 2008. + [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. 9.2. Informative References [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th 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. - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, - "OpenPGP Message Format", RFC 2440, November 1998. - [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. - [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail - Extensions (S/MIME) Version 3.1 Message Specification", - RFC 3851, July 2004. - [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. + [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 4880, November 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. + [RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 5751, January 2010. + Appendix A. Example of Use (INFORMATIVE) This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together. The key used in this example is shown in Appendix C. A.1. The User Composes an Email From: Joe SixPack To: Suzie Q @@ -3153,21 +3198,21 @@ adding their own signatures (e.g., mailing-list-name@example.net). Since (re-)signing is taking responsibility for the content of the message, these signing forwarders are likely to be selective, and forward or re-sign a message only if it is received with a valid signature or if they have some other basis for knowing that the message is not spoofed. A common practice among systems that are primarily redistributors of mail is to add a Sender header field to the message, to identify the address being used to sign the message. This practice will remove - any preexisting Sender header field as required by [RFC2822]. The + any preexisting Sender header field as required by [RFC5322]. The forwarder applies a new DKIM-Signature header field with the signature, public key, and related information of the forwarder. Appendix C. Creating a Public Key (INFORMATIVE) The default signature is an RSA signed SHA256 digest of the complete email. For ease of explanation, the openssl command is used to describe the mechanism by which keys and signatures are managed. One way to generate a 1024-bit, unencrypted private key suitable for DKIM is to use openssl like this: