Network Working Group M. Kucherawy Internet-Draft November 15, 2016 Intended status: Standards Track Expires: May 19, 2017 Including Recipients in DKIM Signatures draft-kucherawy-dkim-rcpts-01 Abstract The DomainKeys Identified Mail (DKIM) protocol applies a domain-level cryptographic signature to an e-mail message. DKIM only guarantees authenticity of the message content and does not consider the message envelope. This allows for replay attacks by recycling a signed message with an arbitrary new set of recipients. This document presents a protocol extension that can include original envelope information in the signature data, so that an altered that information renders the signature invalid. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 May 19, 2017. Copyright Notice Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect Kucherawy Expires May 19, 2017 [Page 1] Internet-Draft DKIM Canonicalized Recipients November 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 'nr' Tag Definition . . . . . . . . . . . . . . . . . . . . . 3 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Compatibility with Current Infrastructure . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.2. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction DKIM [RFC6376] defines a cryptographic signature, placed in a header field consisting of a series of tags and values. The values include signed hashes of some of the header fields and part or all of the body of a message. The signature contains a domain name that is responsible for the signature and thus takes some responsibility for the presence of the message in the email stream. The signature is valid if the hashes in the signature match the corresponding hashes of the message at validation time, the signature is validated by a public key retrieved from that responsible domain's DNS, and it is before the expiration time in the signature header field (if set). There have been recent incidents of a replay attack, where a message of undesirable content (spam, malware, phishing, etc.) is sent by a bad actor to itself through an email service, which dutifully signs it. This message now bears the digital signature of the signing agent's domain, which means in many cases that the signing agent's reputation will be weighed by a receiver when assessing the likely Kucherawy Expires May 19, 2017 [Page 2] Internet-Draft DKIM Canonicalized Recipients November 2016 safety of the message. The bad actor is then free to re-send that message to any number of other recipients with that same signature, any number of times, by altering the set of recipients on the message (the "envelope" in terms of the Simple Mail Transfer Protocol (SMTP) [RFC5321]) and re-sending it. This was anticipated by [RFC6376] Section 8.6. Obviously a signing agent would be well within its rights and own interests to decline to sign something that looks like it might be unwanted content, but such measures are not fool-proof. What is needed, then, is a way to thwart these sorts of replay attacks. The proposal presented here is to include in the signature data the original recipient the message. A verifier could thereby confirm that the envelope recipient matches the envelope recipient that was used on the message when signed, and take defensive measures when a mismatch is identified. For various operational reasons related to SMTP, covered in Section 5, this extension cannot reliably accommodate messages with multiple envelope recipients, and so use of this extension with a message bearing multiple envelope recipients is undefined. 2. Definitions 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]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. The definition of the "FWS" ABNF token is taken from [RFC6376] Section 2.8. The definition of the "base64string" token is taken from [RFC6376] Section 2.10. A full description of the email ecosystem can be found in [RFC5598]. The "envelope recipient" is the recipient identified in an SMTP [RFC5321] RCPT TO command. 3. 'nr' Tag Definition The following DKIM tags (see [RFC6376] Section 3.5) are introduced: rh= Recipient hash (base64; OPTIONAL). ABNF: sig-rh-tag = %x72.68 [FWS] "=" [FWS] base64string Kucherawy Expires May 19, 2017 [Page 3] Internet-Draft DKIM Canonicalized Recipients November 2016 The output of the SHA hash of the envelope recipient, as described in Section 4. rs= Recipient salt (plain-text; OPTIONAL). ABNF: salt-chars = ( ALPHA / DIGIT ) sig-rs-tag = %x72.73 [FWS] "=" [FWS] 1*8salt-chars If present, this provides a salt that is prepended to the envelope recipient before hashing. Ignored if the "rh" tag is not also present. 4. Implementation This section describes implementation of this extension in detail. 4.1. Signers When producing the canonicalized header using this proposal, the signer takes the following steps: 1. Collect the SMTP recipient to be used for sending the message being signed. 2. Canonicalize the recipient string using NFKC per the string preparation framework described in [RFC7564]. 3. OPTIONAL: Select a sequence of one to eight random alphanumeric ASCII characters. This is the encoding salt. Prepend this to the previous string, and add it to the DKIM-Signature header field being generated as the value of the "rs" tag. 4. Apply the same SHA transformation to the above string as is implied by the signing algorithm to be used in generating this signature. That is, apply SHA1 if the "a=" tag is "rsa-sha1" or SHA256 if the "a=" tag is "rsa-sha256". (See [RFC6376] for a definition of the "a=" tag.) 5. Add to the DKIM-Signature header field an "rh" tag whose value is the base64 encoding of the output of the SHA transformation in the previous step. 6. Continue with header canonicalization hashing, and DKIM-Signature header field construction as defined in [RFC6376]. Kucherawy Expires May 19, 2017 [Page 4] Internet-Draft DKIM Canonicalized Recipients November 2016 4.2. Verifiers When analyzing the DKIM-Signature field on an arriving message that includs the "rh" tag defined in Section 3, the verifier takes the following steps: 1. Collect the SMTP recipient to be used for sending the message being signed. 2. Canonicalize the recipient string using NFKC per the string preparation framework described in [RFC7564]. 3. If an "rs" tag is present in the DKIM-Signature header field being evaluated, prepend its value to the string produced by the previous step. 4. Apply the same SHA transformation to the above string as is implied by the "a=" tag present in the DKIM-Signature header field being evaluated. 5. Apply base64 encoding to the output of the SHA transformation. 6. If the base64 encoding does not exactly match the value of the "rh" tag present in the DKIM-Signature header field being evaluated, report PERMFAIL for this signature and stop processing. 7. Continue with header canonicalization, hashing, and DKIM- Signature header field verification as defined in [RFC6376]. This has the effect of requiring the same recipient on the message at time of receipt (more precisely, at time of verification) as was there at the time of signing of the message. If that is not the case, the "rh" tag values produced at each end will fail to match. This effectively prevents the sort of attack described in Section 1. 5. Compatibility with Current Infrastructure [RFC6376] Section 3.5 requires verifiers to ignore tags they do not understand. Accordingly, the introduction of these tags by signers should have no negative impact on existing (correct) implementations. The restriction on use for multiple-recipient messages is predicated on numerous operational issues, including: o Messages can be split anywhere along their handling path to direct the content along separate paths, such as when different recipients are handled by different mail exchanges; Kucherawy Expires May 19, 2017 [Page 5] Internet-Draft DKIM Canonicalized Recipients November 2016 o Recording all recipients in this way would potentionally expose hidden recipeints (e.g., Bcc) to parties that would not otherwise be able to detect them; o A message indicating multiple recipients would fail to verify if some of those recipients were deferred by the receiving system for valid operational reasons such as recipient count limits or invalid recipients. 6. IANA Considerations IANA is requested to register the following in the "DKIM-Signature Tag Specifications" registry: Type: rh Reference: [this document] Status: active Type: rs Reference: [this document] Status: active 7. Privacy Considerations The recipients of a message are not typically recorded anywhere in the message content itself and is instead a property of the SMTP "envelope" used to transport it that is discarded on delivery. This results in the ability to, among other things, do a "blind carbon copy" of a message that does not reveal one recipient to the others. This proposal adds the full recipient address to the content presented for hashing and ultimate transmission of the message. It does not expose that content to receivers visibly, so there is not a direct leak of potentially private information. However, by attaching even an encoded form of the recipient allows an attacker to make an educated guess about who the recipient might be, repeat the algorithm described in Section 4.2, and determine if the guess is correct. 8. Security Considerations Section 8 of [RFC6376] enumerates known security issues with DKIM. In particular, Section 8.6 of [RFC6376] anticipated this attack. Kucherawy Expires May 19, 2017 [Page 6] Internet-Draft DKIM Canonicalized Recipients November 2016 The issues of compatibility discussed in [RFC6376] are unfortunately the ideal. It is possible or even likely that introducing a new DKIM tag that requires verifier participation for success will result in rejection of otherwise legitimate messages, the impact of which depends almost entirely on the sensitivity of the content thus rejected. Apart from the privacy-specific discussion in Section 7, and the potential impact on current infrastructure discussed in Section 5, no new security issues are introduced here. 9. Implementation Status The next release of OpenDKIM will implement this proposal. OpenDKIM is in widespread use, including at very large installations, so use and utility of this extension can be easily observed. 10. Change Log 10.1. 01 o Change "nr" to "rh" and "rs". 10.2. 00 o Initial version. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . Kucherawy Expires May 19, 2017 [Page 7] Internet-Draft DKIM Canonicalized Recipients November 2016 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, . 11.2. Informative References [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . Appendix A. Acknowledgments Valuable input to this proposal was provided by Michael Adkins, Peter Blair, Dave Crocker, Vladimir Dubrovin, Ned Freed, Steven Jones, John Levine, Scott Kitterman, Martijn Grooten, and Alexey Toptygin. Author's Address Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 Phone: +1 415 505 6296 Email: superuser@gmail.com Kucherawy Expires May 19, 2017 [Page 8]