--- 1/draft-ietf-dkim-rfc4871bis-04.txt 2011-03-28 22:16:10.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-05.txt 2011-03-28 22:16:11.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871 (if approved) T. Hansen, Ed. Intended status: Standards Track AT&T Laboratories Expires: September 29, 2011 M. Kucherawy, Ed. Cloudmark March 28, 2011 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-04 + draft-ietf-dkim-rfc4871bis-05 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 @@ -100,55 +100,56 @@ 5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 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 . . . . . . . . . . . 54 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 - 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 - 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 + 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 + 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 - 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 + 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 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.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 61 + 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.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 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 - Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 - Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 + Appendix D. Removal of Key Granularity . . . . . . . . . . . . . 74 + Appendix E. MUA Considerations . . . . . . . . . . . . . . . . . 74 + Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 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 @@ -2332,205 +2333,212 @@ 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 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 [RFC5226]. + 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 + status which MUST be one of "active" (in current use) or "historic" + (no longer in current use). 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: - +------+-----------------+ - | TYPE | REFERENCE | - +------+-----------------+ - | v | (this document) | - | a | (this document) | - | b | (this document) | - | bh | (this document) | - | c | (this document) | - | d | (this document) | - | h | (this document) | - | i | (this document) | - | l | (this document) | - | q | (this document) | - | s | (this document) | - | t | (this document) | - | x | (this document) | - | z | (this document) | - +------+-----------------+ + +------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +------+-----------------+--------+ + | v | (this document) | active | + | a | (this document) | active | + | b | (this document) | active | + | bh | (this document) | active | + | c | (this document) | active | + | d | (this document) | active | + | h | (this document) | active | + | i | (this document) | active | + | l | (this document) | active | + | q | (this document) | active | + | s | (this document) | active | + | t | (this document) | active | + | x | (this document) | active | + | z | (this document) | active | + +------+-----------------+--------+ Table 1: DKIM-Signature Tag Specification Registry Initial Values 7.2. DKIM-Signature Query Method Registry The "q=" tag-spec (specified in Section 3.5) provides for a list of query methods. IANA has established the DKIM-Signature Query Method Registry for mechanisms that can be used to retrieve the key that will permit validation processing of a message signed using DKIM. The initial entry in the registry comprises: - +------+--------+-----------------+ - | TYPE | OPTION | REFERENCE | - +------+--------+-----------------+ - | dns | txt | (this document) | - +------+--------+-----------------+ + +------+--------+-----------------+--------+ + | TYPE | OPTION | REFERENCE | STATUS | + +------+--------+-----------------+--------+ + | dns | txt | (this document) | active | + +------+--------+-----------------+--------+ DKIM-Signature Query Method Registry Initial Values 7.3. DKIM-Signature Canonicalization Registry The "c=" tag-spec (specified in Section 3.5) provides for a specifier for canonicalization algorithms for the header and body of the message. IANA has established the DKIM-Signature Canonicalization Algorithm Registry for algorithms for converting a message into a canonical form before signing or verifying using DKIM. + The initial entries in the header registry comprise: + + +---------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +---------+-----------------+--------+ + | simple | (this document) | active | + | relaxed | (this document) | active | + +---------+-----------------+--------+ + + DKIM-Signature Header Canonicalization Algorithm Registry + Initial Values + The initial entries in the body registry comprise: - +---------+-----------------+ - | TYPE | REFERENCE | - +---------+-----------------+ - | simple | (this document) | - | relaxed | (this document) | - +---------+-----------------+ + +---------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +---------+-----------------+--------+ + | simple | (this document) | active | + | relaxed | (this document) | active | + +---------+-----------------+--------+ DKIM-Signature Body Canonicalization Algorithm Registry Initial Values 7.4. _domainkey DNS TXT Record Tag Specifications A _domainkey DNS TXT record provides for a list of tag specifications. IANA has established the DKIM _domainkey DNS TXT Tag Specification Registry for tag specifications that can be used in DNS TXT Records. The initial entries in the registry comprise: - +------+-----------------+ - | TYPE | REFERENCE | - +------+-----------------+ - | v | (this document) | - | g | (this document) | - | h | (this document) | - | k | (this document) | - | n | (this document) | - | p | (this document) | - | s | (this document) | - | t | (this document) | - +------+-----------------+ + +------+-----------------+----------+ + | TYPE | REFERENCE | STATUS | + +------+-----------------+----------+ + | v | (this document) | active | + | g | [RFC4871] | historic | + | h | (this document) | active | + | k | (this document) | active | + | n | (this document) | active | + | p | (this document) | active | + | s | (this document) | active | + | t | (this document) | active | + +------+-----------------+----------+ DKIM _domainkey DNS TXT Record Tag Specification Registry Initial Values - The initial entries in the body registry comprise: - - +---------+-----------------+ - | TYPE | REFERENCE | - +---------+-----------------+ - | simple | (this document) | - | relaxed | (this document) | - +---------+-----------------+ - - DKIM-Signature Body Canonicalization Algorithm Registry - Initial Values - 7.5. DKIM Key Type Registry The "k=" (specified in Section 3.6.1) and the "a=" (specified in Section 3.5) tags provide for a list of mechanisms that can be used to decode a DKIM signature. IANA has established the DKIM Key Type Registry for such mechanisms. The initial entry in the registry comprises: - +------+-----------+ - | TYPE | REFERENCE | - +------+-----------+ - | rsa | [RFC3447] | - +------+-----------+ + +------+-----------+--------+ + | TYPE | REFERENCE | STATUS | + +------+-----------+--------+ + | rsa | [RFC3447] | active | + +------+-----------+--------+ DKIM Key Type Initial Values 7.6. DKIM Hash Algorithms Registry The "h=" (specified in Section 3.6.1) and the "a=" (specified in Section 3.5) tags provide for a list of mechanisms that can be used to produce a digest of message data. IANA has established the DKIM Hash Algorithms Registry for such mechanisms. The initial entries in the registry comprise: - +--------+-------------------+ - | TYPE | REFERENCE | - +--------+-------------------+ - | sha1 | [FIPS-180-2-2002] | - | sha256 | [FIPS-180-2-2002] | - +--------+-------------------+ + +--------+-------------------+--------+ + | TYPE | REFERENCE | STATUS | + +--------+-------------------+--------+ + | sha1 | [FIPS-180-2-2002] | active | + | sha256 | [FIPS-180-2-2002] | active | + +--------+-------------------+--------+ DKIM Hash Algorithms Initial 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 types. The initial entries in the registry comprise: - +-------+-----------------+ - | TYPE | REFERENCE | - +-------+-----------------+ - | email | (this document) | - | * | (this document) | - +-------+-----------------+ + +-------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +-------+-----------------+--------+ + | email | (this document) | active | + | * | (this document) | active | + +-------+-----------------+--------+ DKIM Service Types Registry Initial Values 7.8. DKIM Selector Flags Registry The "t=" tag (specified in Section 3.6.1) provides for a list of flags to modify interpretation of the selector. IANA has established the DKIM Selector Flags Registry for additional flags. The initial entries in the registry comprise: - +------+-----------------+ - | TYPE | REFERENCE | - +------+-----------------+ - | y | (this document) | - | s | (this document) | - +------+-----------------+ + +------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +------+-----------------+--------+ + | y | (this document) | active | + | s | (this document) | active | + +------+-----------------+--------+ DKIM Selector Flags Registry Initial Values 7.9. DKIM-Signature Header Field IANA has added DKIM-Signature to the "Permanent Message Header Fields" registry (see [RFC3864]) for the "mail" protocol, using this document as the reference. 8. Security Considerations @@ -2823,35 +2831,35 @@ include From: and Subject:, The resulting message violates section 3.6 of [RFC5322]. The way such input will be handled and displayed by an MUA is unpredictable, but in some cases it might display the newly added header fields rather than those that are part of the originally signed message alongside some "valid DKIM signature" annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject:, From: or To: field. - Because of this, DKIM implementers are strongly advised to reject or - treat as suspicious any message that has multiple copies of header - fields that are disallowed by section 3.6 of [MAIL], particularly - those that are typically displayed to end users (From:, To:, Cc:, + Because of this, implementers are strongly advised to reject or treat + as suspicious any message that has multiple copies of header fields + that are disallowed by Section 3.6 of [RFC5322] particularly those + that are typically displayed to end users (From:, To:, Cc:, Subject:). A signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. Senders concerned that their messages might be particularly vulnerable to this sort of attack and who do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including 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. 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 @@ -3299,29 +3306,44 @@ $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM This results in the file rsa.public containing the key information similar to this: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI MmPSPDdQPNUYckcQ2QIDAQAB -----END PUBLIC KEY----- + This public-key data (without the BEGIN and END tags) is placed in the DNS: brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") -Appendix D. MUA Considerations +Appendix D. Removal of Key Granularity + + An important change since [RFC4871] is the removal of the "g=" tag + from key records, which enabled signers to constrain use of a signing + key to specific users by requiring a match to the local-part of the + "i=" tag. [RFC4871] also discussed enabling backward compatibility + with DomainKeys [RFC4870] when "g=" is present without a value. + + As use of "g=" is now deprecated, a verifier compliant with this + document will now ignore that tag completely for records that still + contain it. Signers should thus be aware that compliant verifiers + will no longer constrain use of the key based on any value found in a + "g=" tag. + +Appendix E. MUA Considerations 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 @@ -3334,21 +3356,21 @@ 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 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