idnits 2.17.00 (12 Aug 2021) /tmp/idnits40362/draft-kucherawy-dkim-rcpts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 15, 2016) is 2006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7564 (Obsoleted by RFC 8264) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kucherawy 3 Internet-Draft November 15, 2016 4 Intended status: Standards Track 5 Expires: May 19, 2017 7 Including Recipients in DKIM Signatures 8 draft-kucherawy-dkim-rcpts-01 10 Abstract 12 The DomainKeys Identified Mail (DKIM) protocol applies a domain-level 13 cryptographic signature to an e-mail message. DKIM only guarantees 14 authenticity of the message content and does not consider the message 15 envelope. This allows for replay attacks by recycling a signed 16 message with an arbitrary new set of recipients. 18 This document presents a protocol extension that can include original 19 envelope information in the signature data, so that an altered that 20 information renders the signature invalid. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 19, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. 'nr' Tag Definition . . . . . . . . . . . . . . . . . . . . . 3 59 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Compatibility with Current Infrastructure . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 67 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10.1. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 10.2. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 11.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 DKIM [RFC6376] defines a cryptographic signature, placed in a header 79 field consisting of a series of tags and values. The values include 80 signed hashes of some of the header fields and part or all of the 81 body of a message. The signature contains a domain name that is 82 responsible for the signature and thus takes some responsibility for 83 the presence of the message in the email stream. 85 The signature is valid if the hashes in the signature match the 86 corresponding hashes of the message at validation time, the signature 87 is validated by a public key retrieved from that responsible domain's 88 DNS, and it is before the expiration time in the signature header 89 field (if set). 91 There have been recent incidents of a replay attack, where a message 92 of undesirable content (spam, malware, phishing, etc.) is sent by a 93 bad actor to itself through an email service, which dutifully signs 94 it. This message now bears the digital signature of the signing 95 agent's domain, which means in many cases that the signing agent's 96 reputation will be weighed by a receiver when assessing the likely 97 safety of the message. The bad actor is then free to re-send that 98 message to any number of other recipients with that same signature, 99 any number of times, by altering the set of recipients on the message 100 (the "envelope" in terms of the Simple Mail Transfer Protocol (SMTP) 101 [RFC5321]) and re-sending it. This was anticipated by [RFC6376] 102 Section 8.6. 104 Obviously a signing agent would be well within its rights and own 105 interests to decline to sign something that looks like it might be 106 unwanted content, but such measures are not fool-proof. What is 107 needed, then, is a way to thwart these sorts of replay attacks. 109 The proposal presented here is to include in the signature data the 110 original recipient the message. A verifier could thereby confirm 111 that the envelope recipient matches the envelope recipient that was 112 used on the message when signed, and take defensive measures when a 113 mismatch is identified. 115 For various operational reasons related to SMTP, covered in 116 Section 5, this extension cannot reliably accommodate messages with 117 multiple envelope recipients, and so use of this extension with a 118 message bearing multiple envelope recipients is undefined. 120 2. Definitions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. The 127 definition of the "FWS" ABNF token is taken from [RFC6376] 128 Section 2.8. The definition of the "base64string" token is taken 129 from [RFC6376] Section 2.10. 131 A full description of the email ecosystem can be found in [RFC5598]. 133 The "envelope recipient" is the recipient identified in an SMTP 134 [RFC5321] RCPT TO command. 136 3. 'nr' Tag Definition 138 The following DKIM tags (see [RFC6376] Section 3.5) are introduced: 140 rh= Recipient hash (base64; OPTIONAL). 142 ABNF: 144 sig-rh-tag = %x72.68 [FWS] "=" [FWS] base64string 145 The output of the SHA hash of the envelope recipient, as described 146 in Section 4. 148 rs= Recipient salt (plain-text; OPTIONAL). 150 ABNF: 152 salt-chars = ( ALPHA / DIGIT ) 153 sig-rs-tag = %x72.73 [FWS] "=" [FWS] 1*8salt-chars 155 If present, this provides a salt that is prepended to the envelope 156 recipient before hashing. Ignored if the "rh" tag is not also 157 present. 159 4. Implementation 161 This section describes implementation of this extension in detail. 163 4.1. Signers 165 When producing the canonicalized header using this proposal, the 166 signer takes the following steps: 168 1. Collect the SMTP recipient to be used for sending the message 169 being signed. 171 2. Canonicalize the recipient string using NFKC per the string 172 preparation framework described in [RFC7564]. 174 3. OPTIONAL: Select a sequence of one to eight random alphanumeric 175 ASCII characters. This is the encoding salt. Prepend this to 176 the previous string, and add it to the DKIM-Signature header 177 field being generated as the value of the "rs" tag. 179 4. Apply the same SHA transformation to the above string as is 180 implied by the signing algorithm to be used in generating this 181 signature. That is, apply SHA1 if the "a=" tag is "rsa-sha1" or 182 SHA256 if the "a=" tag is "rsa-sha256". (See [RFC6376] for a 183 definition of the "a=" tag.) 185 5. Add to the DKIM-Signature header field an "rh" tag whose value is 186 the base64 encoding of the output of the SHA transformation in 187 the previous step. 189 6. Continue with header canonicalization hashing, and DKIM-Signature 190 header field construction as defined in [RFC6376]. 192 4.2. Verifiers 194 When analyzing the DKIM-Signature field on an arriving message that 195 includs the "rh" tag defined in Section 3, the verifier takes the 196 following steps: 198 1. Collect the SMTP recipient to be used for sending the message 199 being signed. 201 2. Canonicalize the recipient string using NFKC per the string 202 preparation framework described in [RFC7564]. 204 3. If an "rs" tag is present in the DKIM-Signature header field 205 being evaluated, prepend its value to the string produced by the 206 previous step. 208 4. Apply the same SHA transformation to the above string as is 209 implied by the "a=" tag present in the DKIM-Signature header 210 field being evaluated. 212 5. Apply base64 encoding to the output of the SHA transformation. 214 6. If the base64 encoding does not exactly match the value of the 215 "rh" tag present in the DKIM-Signature header field being 216 evaluated, report PERMFAIL for this signature and stop 217 processing. 219 7. Continue with header canonicalization, hashing, and DKIM- 220 Signature header field verification as defined in [RFC6376]. 222 This has the effect of requiring the same recipient on the message at 223 time of receipt (more precisely, at time of verification) as was 224 there at the time of signing of the message. If that is not the 225 case, the "rh" tag values produced at each end will fail to match. 226 This effectively prevents the sort of attack described in Section 1. 228 5. Compatibility with Current Infrastructure 230 [RFC6376] Section 3.5 requires verifiers to ignore tags they do not 231 understand. Accordingly, the introduction of these tags by signers 232 should have no negative impact on existing (correct) implementations. 234 The restriction on use for multiple-recipient messages is predicated 235 on numerous operational issues, including: 237 o Messages can be split anywhere along their handling path to direct 238 the content along separate paths, such as when different 239 recipients are handled by different mail exchanges; 241 o Recording all recipients in this way would potentionally expose 242 hidden recipeints (e.g., Bcc) to parties that would not otherwise 243 be able to detect them; 245 o A message indicating multiple recipients would fail to verify if 246 some of those recipients were deferred by the receiving system for 247 valid operational reasons such as recipient count limits or 248 invalid recipients. 250 6. IANA Considerations 252 IANA is requested to register the following in the "DKIM-Signature 253 Tag Specifications" registry: 255 Type: rh 257 Reference: [this document] 259 Status: active 261 Type: rs 263 Reference: [this document] 265 Status: active 267 7. Privacy Considerations 269 The recipients of a message are not typically recorded anywhere in 270 the message content itself and is instead a property of the SMTP 271 "envelope" used to transport it that is discarded on delivery. This 272 results in the ability to, among other things, do a "blind carbon 273 copy" of a message that does not reveal one recipient to the others. 275 This proposal adds the full recipient address to the content 276 presented for hashing and ultimate transmission of the message. It 277 does not expose that content to receivers visibly, so there is not a 278 direct leak of potentially private information. However, by 279 attaching even an encoded form of the recipient allows an attacker to 280 make an educated guess about who the recipient might be, repeat the 281 algorithm described in Section 4.2, and determine if the guess is 282 correct. 284 8. Security Considerations 286 Section 8 of [RFC6376] enumerates known security issues with DKIM. 287 In particular, Section 8.6 of [RFC6376] anticipated this attack. 289 The issues of compatibility discussed in [RFC6376] are unfortunately 290 the ideal. It is possible or even likely that introducing a new DKIM 291 tag that requires verifier participation for success will result in 292 rejection of otherwise legitimate messages, the impact of which 293 depends almost entirely on the sensitivity of the content thus 294 rejected. 296 Apart from the privacy-specific discussion in Section 7, and the 297 potential impact on current infrastructure discussed in Section 5, no 298 new security issues are introduced here. 300 9. Implementation Status 302 The next release of OpenDKIM will implement this proposal. OpenDKIM 303 is in widespread use, including at very large installations, so use 304 and utility of this extension can be easily observed. 306 10. Change Log 308 10.1. 01 310 o Change "nr" to "rh" and "rs". 312 10.2. 00 314 o Initial version. 316 11. References 318 11.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 326 Specifications: ABNF", STD 68, RFC 5234, 327 DOI 10.17487/RFC5234, January 2008, 328 . 330 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 331 DOI 10.17487/RFC5321, October 2008, 332 . 334 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 335 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 336 RFC 6376, DOI 10.17487/RFC6376, September 2011, 337 . 339 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 340 Preparation, Enforcement, and Comparison of 341 Internationalized Strings in Application Protocols", 342 RFC 7564, DOI 10.17487/RFC7564, May 2015, 343 . 345 11.2. Informative References 347 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 348 DOI 10.17487/RFC5598, July 2009, 349 . 351 Appendix A. Acknowledgments 353 Valuable input to this proposal was provided by Michael Adkins, Peter 354 Blair, Dave Crocker, Vladimir Dubrovin, Ned Freed, Steven Jones, John 355 Levine, Scott Kitterman, Martijn Grooten, and Alexey Toptygin. 357 Author's Address 359 Murray S. Kucherawy 360 270 Upland Drive 361 San Francisco, CA 94127 363 Phone: +1 415 505 6296 364 Email: superuser@gmail.com