--- 1/draft-ietf-dkim-rfc4871bis-10.txt 2011-06-15 20:15:40.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-11.txt 2011-06-15 20:15:40.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871, 5672 T. Hansen, Ed. (if approved) AT&T Laboratories Intended status: Standards Track M. Kucherawy, Ed. -Expires: November 12, 2011 Cloudmark - May 11, 2011 +Expires: December 17, 2011 Cloudmark + June 15, 2011 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-10 + draft-ietf-dkim-rfc4871bis-11 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 @@ -34,21 +34,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 November 12, 2011. + This Internet-Draft will expire on December 17, 2011. Copyright Notice Copyright (c) 2011 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 @@ -77,85 +77,86 @@ 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 3.3. Signing and Verification Algorithms . . . . . . . . . . . 14 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 - 3.6. Key Management and Representation . . . . . . . . . . . . 28 + 3.6. Key Management and Representation . . . . . . . . . . . . 29 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 - 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 - 3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 35 + 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 36 + 3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 36 3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 3.11. Relationship between SDID and AUID . . . . . . . . . . . . 36 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 - 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 + 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 39 - 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 + 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1. Determine Whether the Email Should Be Signed and by - Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2. Select a Private Key and Corresponding Selector Information . . . . . . . . . . . . . . . . . . . . . . . 40 - 5.3. Normalize the Message to Prevent Transport Conversions . . 40 - 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 - 5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 + 5.3. Normalize the Message to Prevent Transport Conversions . . 41 + 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 42 + 5.5. Recommended Signature Content . . . . . . . . . . . . . . 44 5.6. Compute the Message Hash and Signature . . . . . . . . . . 45 - 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 + 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 46 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 - 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 - 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 + 6.1. Extract Signatures from the Message . . . . . . . . . . . 47 + 6.2. Communicate Verification Results . . . . . . . . . . . . . 52 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 - 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 + 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 54 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 - 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 - 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 + 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 55 + 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 56 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 - 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 + 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 57 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 - 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 - 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 + 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 58 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58 + 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 58 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 - 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 + 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 - 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 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.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 + 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 + 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 - 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 62 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 + 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 - A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 - A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 - Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 + A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 + A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 + Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 - Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 - Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 + Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 74 + Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 75 + Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 77 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 1. Introduction DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. 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 @@ -256,24 +257,24 @@ This section defines terms used in the rest of the document. DKIM is designed to operate within the Internet Mail service, as defined in [RFC5598]. Basic email terminology is taken from that specification. Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. These - words take their normative meanings only when they are presented in - ALL UPPER CASE. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. These words take their normative meanings only when they + are presented in ALL UPPER CASE. 2.1. Signers Elements in the mail system that sign messages on behalf of a domain are referred to as signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other agents such as mailing list exploders. In general, any signer will be involved in the injection of a message into the message system in some way. The key issue is that a message must be signed before it leaves the administrative domain of the signer. @@ -395,30 +396,31 @@ Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded as an "=" followed by two hexadecimal digits from the alphabet "0123456789ABCDEF" (no lowercase characters permitted) representing 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. + removed before decoding. Use of characters not listed as "mail-safe" + in [RFC2049] is NOT RECOMMENDED. 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 @@ -581,35 +584,36 @@ INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some senders might prefer to use rsa-sha1 when balancing security strength against performance, complexity, or other needs. In general, however, rsa-sha256 should always be used whenever possible. 3.3.1. The rsa-sha1 Signing Algorithm The rsa-sha1 Signing Algorithm computes a message hash as described - in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. + in Section 3.7 below using SHA-1 [FIPS-180-3-2008] as the hash-alg. 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 signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. The signing algorithm SHOULD use a public exponent of 65537. 3.3.2. The rsa-sha256 Signing Algorithm The rsa-sha256 Signing Algorithm computes a message hash as described - in Section 3.7 below using SHA-256 [FIPS-180-2-2002] as the hash-alg. + in Section 3.7 below using SHA-256 [FIPS-180-3-2008] as the hash-alg. 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 signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. + The signing algorithm SHOULD use a public exponent of 65537. 3.3.3. Key Sizes Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a @@ -718,24 +722,24 @@ at the end of the message body. An empty line is a line of zero length after removal of the line terminator. If there is no body or no trailing CRLF on the message body, a CRLF is added. It makes no other changes to the message body. In more formal terms, the "simple" body canonicalization algorithm converts "0*CRLF" at the end of the body to a single "CRLF". Note that a completely empty or missing body is canonicalized as a single "CRLF"; that is, the canonicalized length will be 2 octets. - The sha1 value (in base64) for an empty body (canonicalized to a + The SHA-1 value (in base64) for an empty body (canonicalized to a "CRLF") is: uoq1oCgLlTqpdDX/iUbLy7J1Wic= - The sha256 value is: + The SHA-256 value is: frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= 3.4.4. The "relaxed" Body Canonicalization Algorithm The "relaxed" body canonicalization algorithm MUST apply the following steps (a) and (b) in order: a. Reduce whitespace: * Ignore all whitespace at the end of lines. Implementations @@ -743,26 +747,25 @@ * Reduce all sequences of WSP within a line to a single SP character. b. Ignore all empty lines at the end of the message body. "Empty line" is defined in Section 3.4.3. If the body is non-empty, but does not end with a CRLF, a CRLF is added. (For email, this is only possible when using extensions to SMTP or non-SMTP transport mechanisms.) - The sha1 value (in base64) for an empty body (canonicalized to a null - input) is: + The SHA-1 value (in base64) for an empty body (canonicalized to a + null input) is: 2jmj7l5rSw0yVb/vlWAYkK/YBwk= - The sha256 value is: + The SHA-256 value is: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= - INFORMATIVE NOTE: It should be noted that the relaxed body canonicalization algorithm may enable certain types of extremely crude "ASCII Art" attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the "simple" body canonicalization algorithm should be used instead. 3.4.5. Body Length Limits A body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in @@ -1009,34 +1018,34 @@ Internationalized domain names MUST be encoded as A-Labels, as described in Section 2.3 of [RFC5890]. ABNF: sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name The AUID is specified as having the same syntax as an email - address, but is not required to have the same semantics. Notably, - 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 - from a namespace unrelated to any mailbox. The details of the - structure and semantics for the namespace are determined by the - Signer. Any knowledge or use of those details by verifiers or - assessors is outside the scope of the DKIM Signing specification. - The Signer MAY choose to use the same namespace for its AUIDs as - its users' email addresses or MAY choose other means of - representing its users. However, the signer SHOULD use the same - AUID for each message intended to be evaluated as being within the - same sphere of responsibility, if it wishes to offer receivers the - option of using the AUID as a stable identifier that is finer - grained than the SDID. + address, but need not have the same semantics. Notably, the + domain name is need not be registered in the DNS -- so it might + not resolve in a query -- and the Local-part MAY be drawn from a + namespace unrelated to any mailbox. The details of the structure + and semantics for the namespace are determined by the Signer. Any + knowledge or use of those details by verifiers or assessors is + outside the scope of the DKIM Signing specification. The Signer + MAY choose to use the same namespace for its AUIDs as its users' + email addresses or MAY choose other means of representing its + users. However, the signer SHOULD use the same AUID for each + message intended to be evaluated as being within the same sphere + of responsibility, if it wishes to offer receivers the option of + using the AUID as a stable identifier that is finer grained than + the SDID. INFORMATIVE NOTE: The Local-part of the "i=" tag is optional because in some cases a signer may not be able to establish a verified individual identity. In such cases, the signer might wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the Local-part of the identity. @@ -1244,21 +1257,21 @@ v= Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1"). If specified, this tag MUST be set to "DKIM1" (without the quotes). This tag MUST be the first tag in the record. Records beginning with a "v=" tag with any other value MUST be discarded. Note that verifiers must do a string comparison on this value; for example, "DKIM1" is not the same as "DKIM1.0". ABNF: - key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 + key-v-tag = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Unrecognized algorithms MUST be ignored. Refer to Section 3.3 for a discussion of the hash algorithms implemented by Signers and Verifiers. The set of algorithms listed in this tag in each record is an operational choice made by the Signer. ABNF: @@ -1339,27 +1356,26 @@ should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the signer. s Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag. That is, the "i=" domain MUST NOT be a subdomain of "d=". Use of this flag is RECOMMENDED unless subdomaining is required. ABNF: + key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 0*( [FWS] ":" [FWS] key-t-tag-flag ) key-t-tag-flag = "y" / "s" / x-key-t-tag-flag x-key-t-tag-flag = hyphenated-word ; for future extension - Unrecognized flags MUST be ignored. - 3.6.2. DNS Binding A binding using DNS TXT records as a key service is hereby defined. All implementations MUST support this binding. 3.6.2.1. Namespace All DKIM keys are stored in a subdomain named "_domainkey". Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for @@ -1370,21 +1386,21 @@ The DNS Resource Record type used is specified by an option to the query-type ("q=") tag. The only option defined in this base specification is "txt", indicating the use of a TXT Resource Record (RR). A later extension of this standard may define another RR type. Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined. - TXT RRs are encoded as described in Section 3.6.1 + TXT RRs are encoded as described in Section 3.6.1. 3.7. Computing the Message Hashes Both signing and verifying message signatures start with a step of computing two cryptographic hashes over the message. Signers will choose the parameters of the signature as described in Signer Actions (Section 5); verifiers will use the parameters specified in the DKIM- Signature header field being verified. In the following discussion, the names of the tags in the DKIM-Signature header field that either exists (when verifying) or will be created (when signing) are used. @@ -1493,22 +1509,22 @@ application of the RSA private key using a single "sign()" primitive. When using such an API, the last two steps in the algorithm would probably be combined into a single call that would perform both the "a-hash-alg" and the "sig-alg". 3.8. Input Requirements DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and - any other relevant message format standards. See Section 8.15 for - additional discussion and references. + any other relevant message format standards. See Section 8.14 and + Section 8.15 for additional discussion and references. 3.9. Output Requirements For each signature that verifies successfully or produces a TEMPFAIL result, the output of a DKIM verifier module MUST include the set of: o The domain name, taken from the "d=" signature tag; and o The result of the verification attempt for that signature. @@ -1835,21 +1851,21 @@ signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. INFORMATIVE EXAMPLE: If the signer wishes to sign two existing Received header fields, and the existing header contains: Received: Received: - Received: + Received: 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 @@ -2338,20 +2354,23 @@ difficult. If a selector cannot be found, is that because the selector has been removed, or was the value changed somehow in transit? If the signature line is missing, is that because it was never there, or was it removed by an overzealous filter? For diagnostic purposes, the exact reason why the verification fails SHOULD be made available and possibly recorded in the system logs. If the email cannot be verified, then it SHOULD be treated the same as all unverified email regardless of whether or not it looks like it was signed. + See Section 8.14 and Section 8.15 for additional discussion and + references. + 7. IANA Considerations DKIM has registered 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 [RFC5226]. This memo updates these registries as described below. Of note is the addition of a new "status" column. All registrations into these namespaces MUST include the name being registered, the document in which it was registered or updated, and an indication of its current @@ -2490,22 +2509,22 @@ mechanisms that can be used to produce a digest of message data. IANA has established the DKIM Hash Algorithms Registry for such mechanisms. The updated entries in the registry comprise: +--------+-------------------+--------+ | TYPE | REFERENCE | STATUS | +--------+-------------------+--------+ - | sha1 | [FIPS-180-2-2002] | active | - | sha256 | [FIPS-180-2-2002] | active | + | sha1 | [FIPS-180-3-2008] | active | + | sha256 | [FIPS-180-3-2008] | active | +--------+-------------------+--------+ DKIM Hash Algorithms Updated Values 7.7. DKIM Service Types Registry The "s=" tag (specified in Section 3.6.1) provides for a list of service types to which this selector may apply. IANA has established the DKIM Service Types Registry for service @@ -2837,23 +2855,23 @@ Sections 3.5 and 5.4 for further discussion of this mechanism. Specific validity rules for all known header fields can be gleaned from the IANA "Permanent Header Field Registry" and the reference documents it identifies. 9. References 9.1. Normative References - [FIPS-180-2-2002] + [FIPS-180-3-2008] U.S. Department of Commerce, "Secure Hash Standard", FIPS - PUB 180-2, August 2002. + PUB 180-3, October 2008. [ITU-X660-1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 1997. [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. @@ -2929,20 +2947,23 @@ 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. [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009. + [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail + (DKIM) Signatures -- Update", RFC 5672, August 2009. + [RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 5751, January 2010. [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010. Appendix A. Example of Use (INFORMATIVE) @@ -3247,21 +3268,21 @@ 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 [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 + The default signature is an RSA signed SHA-256 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: $ openssl genrsa -out rsa.private 1024 For increased security, the "-passin" parameter can also be added to encrypt the private key. Use of this parameter will require entering a password for several of the following steps. Servers may prefer to use hardware cryptographic support. @@ -3316,21 +3337,21 @@ addresses in the domain. This differs from the usage in the original DKIM specification, where a null "g=" value is not valid for any address. In particular, the example public key record in Section 3.2.3 of [RFC4870] with DKIM. Although the "g=" tag has been deprecated in this version of the DKIM specification, signers are advised not to include the "g=" tag in key records because some [RFC4871]-compliant verifiers will be in use for a considerable period to come. -Appendix D. MUA Considerations +Appendix D. MUA Considerations (INFORMATIVE) When a DKIM signature is verified, the processing system sometimes makes the result available to the recipient user's MUA. How to present this information to the user in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message. An MUA might do this with visual cues such as graphics, or it might include the address in an alternate view, or it might even rewrite the original From address using the verified information. Some MUAs @@ -3343,21 +3364,101 @@ unsigned header fields in a way that might be construed by the end user as having been signed. If the message has an l= tag whose value does not extend to the end of the message, the MUA might also hide or mark the portion of the message body that was not signed. The aforementioned information is not intended to be exhaustive. The MUA may choose to highlight, accentuate, hide, or otherwise display any other information that may, in the opinion of the MUA author, be deemed important to the end user. -Appendix E. Acknowledgements +Appendix E. Changes since RFC4871 + + o Abstract and introduction refined based on accumulated experience. + + o Various references updated. + + o Several errata resolved: + + * 1376 applied + + * 1377 applied + + * 1378 applied + + * 1379 applied + + * 1380 applied + + * 1381 applied + + * 1382 applied + + * 1383 discarded (no longer applies) + + * 1384 applied + * 1386 applied + + * 1461 applied + + * 1487 applied + + * 1532 applied + + * 1596 applied + + o Introductory section enumerating relevent architectural documents + added. + + o Introductory section briefly discussing the matter of data + integrity added. + + o Allow tolerance of some clock drift. + + o Drop "g=" tag from key records. The implementation report + indicates that it is not in use. + + o Remove errant note about wildcards in the DNS. + + o Remove SMTP-specific advice in most places. + + o Reduce (non-normative) recommended signature content list, and + rework the text in that section. + + o Clarify signature generation algorithm by rewriting its pseudo- + code. + + o Numerous terminology subsections added, imported from [RFC5672]. + Also began using these terms throughout the document (e.g., SDID, + AUID). + + o Sections added that specify input and output requirements. Input + requirements address a security concern raised by the working + group (see also new sections in Security Considerations). Output + requirements are imported from [RFC5672]. + + o Appendix subsection added discussing compatibility with DomainKeys + ([RFC4870]) records. + + o Refer to [RFC5451] as an example method of communicating the + results of DKIM verification. + + o Remove advice about possible uses of the "l=" signature tag. + + o IANA registry update. + + o Add two new Security Considerations sections talking about + malformed message attacks. + + o Various copy editing. + +Appendix F. Acknowledgements The previous IETF version of DKIM [RFC4871] was edited by: Eric Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael Thomas. That specification was the result of an extended, collaborative effort, including participation by: Russ Allbery, Edwin Aoki, Claus Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark