idnits 2.17.1 draft-kucherawy-dkim-delegate-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 182: '...horized Mediator SHOULD affix its own,...' RFC 2119 keyword, line 238: '...unsigned decimal integer; RECOMMENDED,...' RFC 2119 keyword, line 240: '... beyond which this header field MAY be...' RFC 2119 keyword, line 243: '...itself, any other tag MUST be ignored....' RFC 2119 keyword, line 256: '... Original Signer SHOULD use the same s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2015) is 3305 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5322' is mentioned on line 335, but not defined 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 4 Intended status: Experimental D. Crocker 5 Expires: October 12, 2015 Brandenburg InternetWorking 6 April 10, 2015 8 Delegating DKIM Signing Authority 9 draft-kucherawy-dkim-delegate-02 11 Abstract 13 DomainKeys Identified Mail (DKIM) permits a handling agent to affix a 14 digital signature to an email message, associating a domain name with 15 that message using cryptographic signing techniques. The digital 16 signature typically covers most of a message's original portions, 17 although the specific choices for content hashing are at the 18 discretion of the signer. DKIM signatures survive simply email 19 relaying but typically are invalidated by processing through 20 Mediators, such as mailing lists. For such cases, the signer needs a 21 way to indicate that a valid signature from some third party was 22 anticipated, and constitutes an acceptable handling of the message. 23 This enables a receiver to conclude that the content is legitimately 24 from that original signer, even though its original signature no 25 longer validates. 27 This document defines a mechanism for improving the ability to assess 28 DKIM validity for such messages. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 12, 2015. 47 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. DKIM-Delegate Specification . . . . . . . . . . . . . . . . . 4 66 3.1. Design Summary . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.4. Preparation . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.5. Verification . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 78 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 9 79 Appendix B. To-Do List . . . . . . . . . . . . . . . . . . . . . 10 80 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 82 1. Background 84 DomainKeys Identified Mail [RFC6376] defines a mechanism whereby a 85 verified domain name can be attached to a message, using a 86 cryptographic signature. It does not, however, assert that this 87 domain name matches a domain name found anywhere else in the message. 89 DKIM signature survival is usually successful through basic email 90 relaying nodes. It also survives simple Mediators, such as mailbox 91 forwarding agents, because they only modify the message envelope and 92 do not modify the original message header or body. Transit through 93 other Mediators, such as mailing lists, is usually problematic, 94 because they modify portions of the message covered by the signature 95 and therefore invalidate it. 97 When a receiver needs to determine whether a message was legitimately 98 processed by a purported original signer, a mechanism is needed that 99 is more likely to survive transit through Mediators. This need is 100 especially strong for environments wishing to enforce policy linkage 101 between the author, the author's domain and specific email service 102 providers, such as when the latter two are the same. An example of 103 such a need is when that original signer publishes policies 104 concerning the use of its domain name. Examples are ADSP [RFC5617] 105 and DMARC [I-D.KUCHERAWY-DMARC-BASE]. These policies cannot be 106 applied properly when legitimate mail for the original signer's 107 domain cannot be validated by the final Receiver. The potential for 108 malfunction otherwise is described in Section 5.2 of [RFC6377]. 110 The issues with mailing lists and similar re-mailing applications can 111 be resolved by a mechanism that permits the original signer's domain 112 ("A") to indicate that some other domain ("B") is explicitly 113 permitted to re-sign content generated by "A", such that a Receiver 114 can observe signaling from both "A" and "B" that this relationship 115 exists. 117 An experimental attempt to do this appeared in [RFC6541]. The method 118 presented there imposes a burden on the original signing domain to 119 publish those relationships a priori, via the DNS. This proved 120 cumbersome with poor scaling properties. So, a mechanism that does 121 not have such an external dependency is preferred. 123 2. Definitions 125 Numerous terms used here, especially "Author", "Originator", 126 "Receiver", and "Recipient", are defined in [RFC5598]. DKIM-related 127 terminology, such as "Signing Domain", are taken from the DKIM 128 specification [RFC6376]. 130 3. DKIM-Delegate Specification 132 An email header field, called "DKIM-Delegate", is defined. When 133 present, it asserts an ephemeral relationship between an original 134 message signing domain and a later intermediary (Mediator). 136 3.1. Design Summary 138 An "Original Signer" (typically the Originator serving the Author) 139 affixes a DKIM signatures to a message using whatever parameters it 140 wishes. In addition to this, it affixes a DKIM-Delegate field that 141 indicates an ephemeral relationship exists between the Author domain 142 and some set of other domains that are expected to handle the 143 message. Preferably, the Mediator also signs the message, to provide 144 a reliable confirmation of handling by that Mediator. If a Receiver 145 finds that the Original Signer's "normal" signature does not validate 146 or is missing, it can perform DKIM-Delegate evaluation. 148 The DKIM-Delegate field includes a hash and a cryptographic 149 signature, just like DKIM-Signature fields do. However, the only 150 content covered by the hash is the DKIM-Delegate field and its 151 parameters. 153 In combination with DKIM signatures, this mechanism can aid a 154 receiver in assessing whether the message was legitimately handled by 155 the intermediary and whether the message was likely to have had a 156 legitimate signature by the original signing domain, even when that 157 original signature became invalid. This makes it possible to 158 identify such messages separately from those without these 159 assurances, and thus permits treating the latter with more 160 skepticism. 162 3.2. Mechanism 164 The specific mechanism operates as follows: 166 1. A "Primary" DKIM Signature is affixed to a message by a handling 167 agent, identifying the Originator's domain and using typical 168 signing choices, such as covering the entire message content in 169 the body hash. (That is, it does not use the "l=" tag.) 171 2. The signer adds a DKIM-Delegate header field identifying the 172 Originator's domain. It also identifies the specific domain(s) 173 with which it wishes to claim an ephemeral relationship. The 174 DKIM-Delegate field is self-signed, as described below. 176 3. The Originator transmits the message to the Receiver in the 177 usual way. 179 4. If the Receiver is not a Mediator, then normal DKIM processing 180 occurs, and DKIM-Delegate is ignored. 182 5. An authorized Mediator SHOULD affix its own, normal DKIM 183 signature to the message after making any content modifications 184 it is configured to make and before re-sending the message to 185 new Receiver(s). 187 6. The new Receiver attempts to validate the Primary signature 188 affixed by the original signer. If it is valid, the 189 requirements of this protocol are satisfied (and the algorithm 190 terminates here). 192 7. The new Receiver attempts to validate the DKIM-Delegate field 193 affixed by the original signer. If it is not valid, expired, or 194 absent, the requirements of this protocol cannot be satisfied 195 (and the algorithm terminates here). 197 8. The Receiver extracts the list of domains authorized to re-sign 198 for the Author domain from the "t=" tag of the DKIM-Delegate 199 field. Call this set "D". 201 9. The Receiver performs normal validation checks of all other DKIM 202 signatures on the message that include the entire message body 203 in their body hashes, and stores the set of domains from passing 204 signatures in set "S". 206 10. If the intersection of "D" and "S" is not empty, the 207 requirements of this protocol are satisfied; otherwise, the 208 requirements are not satisfied. 210 3.3. Syntax 212 The content of the DKIM-Delegate header field is a tag-list as 213 defined in Section 3.2 of [RFC6376]. The valid tags are: 215 a= Signature algorithm (plain-text; REQUIRED). As in Section 3.5 of 216 [RFC6376], this contains a string that describes the signature 217 generation algorithm used by the signer. 219 b= Signature data (base64; REQUIRED). As in Section 3.5 of 220 [RFC6376], this contains a digital signature of the content of 221 this header field. The same syntax rules for DKIM signatures 222 apply here. 224 d= Author domain (plain-text; REQUIRED). This value names the domain 225 of the Author, which is delegating signing authority to one or 226 more other domains. 228 s= Selector name (plain-text; REQUIRED). As in Section 3.5 of 229 [RFC6376], this names a particular public/private key pair that is 230 used to sign and verify the content of this header field. It will 231 be used to construct a DNS query for a text representation of the 232 public key. 234 t= Delegation target (plain-text; REQUIRED). This value is a comma- 235 separated list of domain names to which the authority to sign on 236 behalf of the Author domain is being delegated. 238 x= Expiration time (plain-text unsigned decimal integer; RECOMMENDED, 239 default is no expiration) As in Section 3.5 of [RFC6376], this 240 specifies a timestamp beyond which this header field MAY be 241 considered invalid. 243 As with DKIM itself, any other tag MUST be ignored. 245 3.4. Preparation 247 The content of a DKIM-Delegate field is prepared for signing by 248 applying the "relaxed" header canonicalization scheme defined in 249 Section 3.4.2 of [RFC6376] and the algorithm described in Section 250 3.7. For DKIM-Delegate, the only content that is hashed is the 251 constructed DKIM-Delegate field itself, with an empty "b=" tag; 252 notably, there is no "v=" or "bh=" tag, so these are omitted. The 253 signature, once generated, is then added as the value of the "b=" 254 tag. 256 The Original Signer SHOULD use the same selector (and, hence, signing 257 key) for DKIM-Delegate fields as it uses for Primary signatures so 258 that Domain Name Service caching can be used. 260 3.5. Verification 262 A Receiver verifies the DKIM-Delegate field by applying the general 263 algorithm described in Section 6.1 of [RFC6376] with the following 264 caveats: 266 o This specification has a subset of the tags found in a DKIM- 267 Signature. Most notably, DKIM-Delegate has no "v=", "bh=", "c=", 268 or "h=" tag. 270 A DKIM-Delegate field that verifies contains an explicit list of 271 domains authorized to sign content for the Author domain. The 272 Receiver then simply ensures that there is a valid DKIM-Signature 273 from one of the delegated domains before concluding that the Author 274 domain approved the content. 276 4. Expiration 278 The expiration time on the DKIM-Delegate field needs to be long 279 enough to permit evaluation by Receivers of the re-submitted message, 280 yet short enough to limit the potential for unauthorized injection 281 attacks. A good choice is a small number of days or even hours. 283 If abuse is detected, the owner of the Author domain can remove the 284 key from publication in the DNS as a way of revoking that key and 285 thus invalidating any unverified DKIM-Delegate fields. 287 5. Discussion 289 The use of the Primary signature ensures that if the original message 290 arrives unmodified, the Receiver is assured of its legitimacy as 291 having been generated and sent by the original signer, irrespective 292 of what Mediator handled it. 294 Mediators, such as mailing list software, commonly make adjustments 295 to a message prior to re-submitting it for transfer to final 296 recipients. Adjustments often include prepending list-identifying 297 material to the Subject field, or appending URIs and such to the 298 message body referring Receivers to further information about the 299 list itself. This will almost always invalidate the Primary 300 signature, so downstream receivers cannot be sure (via DKIM, at 301 least) where the message originated. 303 6. Security Considerations 305 Use of this header field (and DKIM as described here) amounts to an 306 ephemeral granting of the ability for the first Receivers (typically 307 the Mediators named in the To and Cc fields) to generate content that 308 the ultimate Receivers will consider valid on behalf of the Author. 309 A compromised Mediator can thus replace the original content in its 310 entirety while still satisfying this protocol. 312 The "t=" tag might be used to name Mediators that do not appear in 313 the To or Cc fields of a message, which means they would normally 314 appear in the message envelope only. Thus, use of that tag records 315 envelope details in the message, which could be information intended 316 to be kept private. 318 As described in Section 3.2, this mechanism signature presents a 319 time-limited but nevertheless present opportunity for someone at the 320 Mediator's domain to generate content apparently authorized by the 321 Author domain. 323 Given the exposures described above, message originators would do 324 well to consider limiting use of this protocol to those messages that 325 will transit trusted Mediators only. Determining which Mediators are 326 worthy of such trust is a local policy matter, outside of the scope 327 of this document. 329 7. IANA Considerations 331 IANA is requested to make the following new entry in the Permanent 332 Message Header Field Names registry, per [RFC3864]: 334 Header field name: DKIM-Delegate 335 Applicable protocol: mail ([RFC5322]) 336 Status: Experimental 337 Author/Change controller: IETF 338 Specification document(s): [this document] 339 Related information: 340 Requesting review of any proposed changes and additions to 341 this field is recommended. 343 8. References 345 8.1. Normative References 347 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, 348 "Registration Procedures for Message 349 Header Fields", BCP 90, RFC 3864, 350 September 2004. 352 [RFC6376] Crocker, D., Hansen, T., and M. 353 Kucherawy, "DomainKeys Identified Mail 354 (DKIM) Signatures", STD 76, RFC 6376, 355 September 2011. 357 8.2. Informative References 359 [I-D.KUCHERAWY-DMARC-BASE] Kucherawy, M., Ed. and E. Zwicky, Ed., 360 "Domain-based Message Authentication, 361 Reporting and Conformance (DMARC)", 362 I-D draft-kucherawy-dmarc-base. 364 [RFC5598] Crocker, D., "Internet Mail 365 Architecture", RFC 5598, July 2009. 367 [RFC5617] Allman, E., Fenton, J., Delany, M., and 368 J. Levine, "DomainKeys Identified Mail 369 (DKIM) Author Domain Signing Practices 370 (ADSP)", RFC 5617, August 2009. 372 [RFC6377] Kucherawy, M., "DomainKeys Identified 373 Mail (DKIM) and Mailing Lists", BCP 167, 374 RFC 6377, September 2011. 376 [RFC6541] Kucherawy, M., "DomainKeys Identified 377 Mail (DKIM) Authorized Third-Party 378 Signatures", RFC 6541, February 2012. 380 Appendix A. Example 382 Given the following message header (numbers in braces are line 383 numbers): 385 {1} From: somebody@example.com 386 {2} To: mailinglist@ietf.example 387 {3} Subject: What's up with DKIM? 388 {4} Date: Thu, 12 Jun 2014 11:08:10 -0700 389 {5} DKIM-Signature: v=1; s=rashani; d=example.com; 390 {6} h=from:to:subject:date; ... 391 {7} DKIM-Delegate: a=rsa-sha256; d=example.com; s=rashani; 392 {8} x=1402686254; t=ietf.example; b= 393 {9} 394 {10} [message body omitted] 396 The DKIM signature (line 5) is an Author signature that covers the 397 entire message body (the "Primary" signature). If it validates on 398 delivery, the remainder of the DKIM material can be ignored. 400 There is also a DKIM-Delegate header field (line 7) that identifies 401 the delegating party in its "d=" tag. It states that signing 402 authority is delegated by "example.com" to "ietf.example" (the 403 Mediator domain). The integrity of this field is assured by the fact 404 that its signature verified. 406 On receipt at the Mediator, both signatures will typically validate. 407 The Mediator then augments the content as needed and re-sends the 408 message for delivery, this time adding its own signature: 410 {1} From: somebody@example.com 411 {2} To: mailinglist@ietf.example 412 {3} Subject: What's up with DKIM? 413 {4} Date: Thu, 12 Jun 2014 11:08:10 -0700 414 {5} DKIM-Signature: v=1; s=rashani; d=example.com; 415 {6} h=from:to:subject:date; ... 416 {7} DKIM-Delegate: a=rsa-sha256; d=example.com; s=rashani; 417 {8} x=1402686254; t=ietf.example; b= 418 {9} List-Id: mailinglist.ietf.example 419 {10} DKIM-Signature: v=1; s=evetastic; d=ietf.example; 420 {11} h=from:to:subject:date:dkim-delegate:list-id; ... 421 {12} 422 {13} [augmented message body omitted] 424 Because of the changed content, the Primary signature no longer 425 validates. However, the Mediator signature will presumably validate 426 on receipt, since it covers all of the modified content. In 427 addition, the DKIM-Delegate field would be expected to validate as it 428 is unlikely to be altered by Mediators. 430 The Receiver of this message (a list subscriber, in this case) can 431 conclude that the following are true, based on the remaining valid 432 signatures: 434 1. "example.com" authorized "ietf.example" to sign mail on its 435 behalf; 437 2. "ietf.example" signed the altered content, thus taking some 438 responsibility for it; 440 3. This chain of handling satisfies the need for the Author domain 441 to have signed the message; the original message may have been 442 modified or replaced, but such action was explicitly approved by 443 the Author domain. 445 Appendix B. To-Do List 447 Stuff to be done: 449 o (nothing right now) 451 Some suggestions from others: 453 o Perhaps this is better done by one or more new DKIM-Signature tags 454 and/or a version change. (From John Levine) 456 Appendix C. Acknowledgments 458 The authors wish to acknowledge Steve Atkins, Barry Leiba, Pete 459 Resnick, Hector Santos, Stephen Turnbull, Alessandro Vesely, (other 460 names) for their comments during the development of this document. 462 Authors' Addresses 464 Murray S. Kucherawy 466 EMail: superuser@gmail.com 468 D. Crocker 469 Brandenburg InternetWorking 470 675 Spruce Dr. 471 Sunnyvale 94086 472 USA 474 Phone: +1.408.246.8253 475 EMail: dcrocker@bbiw.net 476 URI: http://bbiw.net