idnits 2.17.1 draft-kucherawy-dkim-transform-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 : ---------------------------------------------------------------------------- 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 date (July 5, 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 163, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) 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 July 5, 2020 4 Intended status: Experimental 5 Expires: January 6, 2021 7 Recognized Transformations of Messages Bearing DomainKeys Identified 8 Mail (DKIM) Signatures 9 draft-kucherawy-dkim-transform-02 11 Abstract 13 DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a 14 mail operator can affix a signature to a message that validates at 15 the level of the signer's domain name. It specified two possible 16 ways of converting the message body to a canonical form, one 17 intolerant of changes and the other tolerant of simple changes to 18 whitespace within the message body. 20 The provided canonicalization schemes do not tolerate changes in a 21 message such as conversion between transfer encodings or addition of 22 new message content. It is useful to have these capabilities to 23 allow for transport through gateways, and also for transport through 24 handlers (such as mailing list services) that might add content that 25 would invalidate a signature generated using the existing 26 canonicalization schemes. 28 This document presents a mechanism for declaring that a message 29 underwent any of a handful of well-defined transformations prior to 30 being re-signed by a mediator, so that a verifier might rewind such 31 modification(s) and thereby confirm that the original signature still 32 verifies against the original content. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 6, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The 'tf' DKIM Signature Tag . . . . . . . . . . . . . . . . . 4 70 4. DKIM Operational Flow . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. The 'subject' Transformation . . . . . . . . . . . . . . . . . 6 73 6. The 'footer' Transformation . . . . . . . . . . . . . . . . . 6 74 7. The 'mimeify' Transformation . . . . . . . . . . . . . . . . . 7 75 8. The 'add-part' Transformation . . . . . . . . . . . . . . . . 8 76 9. The 'mime-wrap' Transformation . . . . . . . . . . . . . . . . 9 77 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 11.1. Imported from DKIM . . . . . . . . . . . . . . . . . . . . 11 80 11.2. False Transformation Claims . . . . . . . . . . . . . . . 12 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 12.1. DKIM Transformations Registry . . . . . . . . . . . . . . 12 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 14 87 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 88 Appendix C. To-Do List . . . . . . . . . . . . . . . . . . . . . 15 89 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 16 91 1. Background 93 DomainKeys Identified Mail (DKIM) [RFC6376] defines a mechanism 94 whereby a verified domain name can be attached to a message, or 95 portion of a message, using a cryptographic signature. It presents 96 two possible schemes for converting the header block to a canonical 97 form, and similarly two schemes for canonicalizing the body. In each 98 case, one scheme permits no changes whatsoever, and the other permits 99 limited changes restricted to areas such as whitespace munging, case 100 changing, and header field wrapping. 102 Some agents deliberately, but innocently, modify content in transit. 103 A prime example of this is mailing lists, which might add a prefix to 104 the Subject field of a message, add list-specific information to the 105 header (in the form of new header fields), or append administrivia to 106 the body of messages before they are re-mailed to the list 107 subscribers. Use of mailing lists with respect to DKIM, and a 108 discussion of related challenges, can be found in [RFC6377]. The 109 urgency to solve this family of problems increased dramatically with 110 the large-scale introduction of Domain-based Message Authentication, 111 Reporting, and Conformance (DMARC) [RFC7489]. 113 There is a desire to have DKIM signatures survive transit through 114 lists. One way to do this is to make use of DKIM's "l=" tag which 115 limits the portion of the body that is signed. This exposes an 116 attack vector, however, since one can simply append any content to a 117 partly-signed message and the signature will continue to verify. 118 (See Section 8.2 of [RFC6376].) 120 This document defines an incremental mechanism to declare that a 121 signature is being applied to message content after some number of a 122 small set of well-defined, reversible content transformations. The 123 message verifier can then reverse the effect of the claimed 124 transformation(s) and, theoretically, recover the original content 125 and confirm its integrity relative to an original signature. 127 The utility of this mechanism is predicated on the notion that agents 128 that modify signed messages will do using only the known (registered) 129 transformations, and that common transformations will be registered 130 as they are developed. 132 2. Definitions 134 Numerous terms used here, especially "Author" and "Mediator", are 135 defined in [RFC5598]. 137 For the purposes of this experiment, a transformation is "reversible" 138 if at the time the message is received, the verifier has enough 139 information to recover the pre-transformation content. For example, 140 a transformation that removes a MIME part with an undesired media 141 type or filename extension cannot be undone by the receiver because 142 it cannot restore content it doesn't have; such a transformation is 143 not reversible and thus not a candidate for consideration here. 144 However, a transformation that adds a specific header field to a 145 message is reversible because the verifier can simply remove the 146 header field. 148 3. The 'tf' DKIM Signature Tag 150 This section defines the 'tf' DKIM signature tag. 152 The presence of this tag is an indication to a verifier that the 153 agent adding this signature transformed the original message between 154 receipt (and verification of any previously-applied signature) and 155 retransmission, and that such transmission was one of a set that are 156 common, well-defined, and reversible. 158 The value of this tag is one of the transformations registered in the 159 DKIM Message Transformations registry. See Section 12. 161 Using ABNF, as defined in [RFC5234]: 163 sig-tf-tag = %x74.66 [FWS] "=" [FWS] sig-tf-tag-trans 164 sig-tf-tag-trans = Token *("," Token) 165 ; expected to be a list of one or more 166 ; transformation names found in the DKIM 167 ; Message Transformations registry 169 "Token" is imported from [RFC2045], and "FWS" is imported from 170 [RFC6376]. 172 A verifier finding a signature with the "tf" tag present but bearing 173 a value it does not recognize ignores its presence (other than 174 including it in hash computation). 176 4. DKIM Operational Flow 178 In all cases, DKIM operations involving this tag begin with a message 179 author generating content and submitting it to the appropriate 180 Message Submission Agent (MSA). The MSA is presumed to have some 181 kind of DKIM signature generation capability, and thus the message 182 will have an author domain signature attached to it. 184 When a message arrives at a Mediator or other intermediary that 185 wishes to distribute an altered form of the author's content, such as 186 a Mailing List Manager (MLM) configured to do so, it generates an 187 additional DKIM signature with the new form of the content as input. 188 This second includes the "tf" tag, announcing which known 189 transformation(s) was applied to the message prior to creation of the 190 Mediator's signature. Importantly, the original signature is not 191 removed from the message nor is it altered in any way. 193 Since DKIM-compliant verifiers ignore signature tags of which they 194 are not aware, this is a purely incremental change as it will not 195 interfere with the deployed DKIM infrastructure. 197 A DKIM verifier aware of this tag will first confirm that the 198 Mediator's signature is valid. On doing so, it can then apply the 199 reverse of the claimed transformation. This will restore the message 200 to the form and content originally submitted by the Author, and the 201 Author's signature will then be valid over the restored content. 203 This might be used to confirm that a message which passed through a 204 Mediator can still be considered to have a valid Author signature, 205 satisfying policy checks such as those described in [RFC7489]. 207 4.1. Detail 209 1. Author A generates message M, addressed to recipient R, which is 210 a Mediator (a mailing list manager, for example). 212 2. Author submits M to its MSA. 214 3. MSA generates and attaches DKIM signature S(M), and sends the 215 message toward its destination, which is the servers accepting 216 messages for R. 218 4. The message arrives at R. R might verify signature S(M) and apply 219 any local policy if the verification fails. 221 5. R selects an ordered list of one or more of the registered, 222 reversible transformations, T1, T2, etc., to be applied to M. The 223 complete list is referred to as T. (The reverse operations will 224 be called T' as an ordered list, whose order is the reverse of T, 225 and the individual reverse transformations are called T1', T2', 226 etc.) R thus generates T(M) as the new content. The new content 227 necessarily includes S(M). 229 6. R also generates a signature of T(M), which is S(T(M)). This new 230 signature includes the "tf" tag defined above, identifying the 231 ordered sequence of transformations T that was used in the 232 previous step. It then sends the message toward its final 233 destination(s). For a mailing list manager, this would be all of 234 the current list subscribers. 236 7. The Mediator version of the message arrives at ultimate recipient 237 Z. Assuming no unexpected damage to the message in transit, Z 238 will be able to validate S(T(M)). 240 8. If the verifier is not aware of this tag and its meaning, or if 241 the verifier is not aware of how to reverse the identified 242 transformation, normal DKIM verification continues from here, and 243 this modified algorithm terminates. It would be expected that 244 S(T(M)) would be valid, but S(M) would not. 246 9. The compliant verifier applies T' to the validated message 247 content. By definition, T'(T(M)) is M. (If this is not true, 248 then at least one of the original transformations was not 249 reversible.) Since the Mediator preserved Author signature S(M), 250 the verifier can now attempt to validate the Author signature 251 against the recovered original content. 253 5. The 'subject' Transformation 255 Mailing list services commonly apply a "tag" to the Subject field of 256 a message identifying the message as having been distributed as part 257 of a list. By far the most common tag method is to prefix the 258 Subject field with the name of the list in square brackets (ASCII 259 0x5b and 0x5d), possibly followed by a space and a sequence number. 260 Accordingly, this transformation describes exactly such a mutation. 261 Specifically, the mutation is the addition of a string to the 262 beginning of the Subject field comprised of alphanumeric characters, 263 a limited set of punctation, or digits, surrounded by square 264 brackets, possibly including and followed by whitespace. In ABNF 265 terms, the string is described by: 267 s-punct = 0x45 / 0x5f / 0x2f / 0x20 / 0x2e 268 s-tag = 0x5b 1*( ALPHA / DIGIT / s-punct ) 0x5d 1*FWS 270 Thus, the reverse operation is simply the removal of any such 271 substring at the front of the Subject field. 273 If there is no Subject field prefix matching the above ABNF, then the 274 transformation reversal cannot be computed and an error is returned. 276 6. The 'footer' Transformation 278 Mailing lists sometimes add a "footer" to a message, typically 279 consisting of a small number of lines of text identifying the name of 280 the list and some other administrivia, and usually including a URL 281 where subscriptions can be managed or list archives can be found. 282 Such trivial text edits are reversible, so these too are a candidate 283 for this mechanism. 285 A "footer" for the purposes of this capability is all text below a 286 trivial boundary marker. A boundary comprises a line of text made up 287 solely of two or more hyphen or underscore (0x2d or 0x5f) characters. 288 Therefore, reversing this transformation is accomplished by searching 289 backwards, a line at a time, from the end of the message, until such 290 a line is found. When found, the message is truncated such that the 291 line and all lines after it are removed. 293 If no such line is found, then the transformation reversal cannot be 294 computed and an error is returned. 296 7. The 'mimeify' Transformation 298 The "mimeify" transformation converts a message that is not formatted 299 according to Multipurpose Internet Mail Extensions (MIME) [RFC2045], 300 and converts it to that form. This allows a Mediator to place the 301 original content in one MIME part, and its own additional content in 302 a second MIME part. The reverse transformation is to remove the 303 second MIME part altogether, and then strip away all MIME structure, 304 leaving only the original author content. 306 More specifically, the transformation follows these steps: 308 1. A "MIME-Version" header field is added, as described in 309 [RFC2045]. 311 2. A "Content-Type" header field is added, also as described in 312 [RFC2045]. The media type is "multipart/mixed". A unique 313 compliant boundary is also generated. 315 3. Two MIME parts are created. The first MIME part is of type 316 "text/plain", and contains the body of the original message. The 317 second MIME part contains whatever content the Mediator is 318 configured to add, and uses a media type appropriate to that 319 content. 321 4. The body of the message is replaced with the following, in a 322 manner compliant with [RFC2045], namely: 324 A. the boundary; 326 B. an optional "Content-Type" header field indicating the 327 original content used the default "text/plain" media type, 328 and the optional "charset" parameter; 330 C. a line break; 331 D. the body of the original message; 333 E. a line break; 335 F. the boundary; 337 G. any MIME header fields needed to introduce the content the 338 Mediator wishes to add; 340 H. a line break; 342 I. the Mediator's content; 344 J. the terminating boundary. 346 The reverse of this transformation is as follows: 348 1. Extract the full content of the first MIME part. 350 2. Discard the entire message body, and replace it with the 351 extracted content above. 353 3. Remove the "Content-Type" and "MIME-Version" header fields. 355 If any setp cannot be completed because the stated header field or 356 content cannot be located, an error is returned. 358 8. The 'add-part' Transformation 360 The "add-part" transformation augments a multipart message that is 361 already formatted according to MIME by appending an additional part 362 that includes the content the Mediator wishes to add. 364 This transformation cannot be used unless the media type of the 365 message as a whole (the one named in the Content-Type field in the 366 header of the message itself) is "multipart/mixed". Simply put, a 367 new part within the existing set of parts is added at the end, 368 containing the Mediator's content. 370 More specifically, the transformation follows these steps: 372 1. Determine the MIME boundary used to separate parts, found in the 373 top-level Content-Type header field. 375 2. At the point of the terminating boundary in the original message, 376 insert a non-terminating instance of the same boundary. 378 3. After the new boundary, write any MIME fields needed to introduce 379 the content the Mediator wishes to add. 381 4. Insert a line break, followed by the Mediator's content, and an 382 additional line break. 384 The reverse of this transformation is as follows: 386 1. Locate the last instance of the boundary found in the Content- 387 Type header field of the message itself. 389 2. Delete the content from that point in the message until the 390 terminating instance of the boundary. 392 If any setp cannot be completed because the stated MIME part cannot 393 be located, an error is returned. 395 9. The 'mime-wrap' Transformation 397 The "mime-wrap" transformation augments a message that is already 398 formatted according to MIME by enclosing the existing MIME structure 399 in a new layer. This new layer contains two parts: the original MIME 400 structure in its first part, and the Mediator content in its second 401 part. 403 More specifically, the transformation follows these steps: 405 1. Remove the Content-Type header field from the message. 407 2. Generate a new Content-Type header field, compliant with 408 [RFC2045], with media type "multipart/mixed", and a boundary. 410 3. The body of the message is replaced with the following, in a 411 manner compliant with [RFC2045], namely: 413 A. the new boundary; 415 B. the previously deleted Content-Type header field; 417 C. a line break; 419 D. the entire original content of the message; 421 E. a line break; 423 F. the new boundary; 424 G. any MIME header fields needed to introduce the content the 425 Mediator wishes to add; 427 H. a line break; 429 I. the Mediator's content; 431 J. the terminating instance of the new boundary. 433 This leaves the new message as a MIME message with two parts at the 434 outermost layer; the original message appears as the first part, and 435 the Mediator's content is the second part. 437 The reverse of this transformation is as follows: 439 1. Extract the Content-Type header field from the first MIME part in 440 the message. This appears immediately after the first MIME 441 boundary in the message. 443 2. Replace the Content-Type header field of the message with the one 444 extracted above. 446 3. Extract the content of the first MIME part in the message. This 447 appears between the first two instances of the outermost MIME 448 boundary. 450 4. Replace the entire message body with the extracted MIME part. 452 If any setp cannot be completed because the stated MIME part cannot 453 be located, an error is returned. 455 10. Discussion 457 Section 3.5 of [RFC6376] defined an optional DKIM signature tag 458 ("z=") that can be used to reconstruct the header field set that was 459 signed by the author. When a signature fails to verify, this 460 information could conceivably be used to replay the correct 461 (original) header fields through canonicalization and possibly yield 462 a passing result. 464 Doing this augmented replay blindly would allow a signature to pass 465 when it failed because some alteration correctly rendered the 466 original content invalid or even dangerous. This is manifestly not 467 an error. Identifying which mutations of the original content ought 468 to be permissible necessarily relies on heuristics and possibly local 469 knowledge. However, a mutation universally considered to be 470 tolerable should become part of the canonicalization process rather 471 than being identified and handled in this manner. Moreover, if two 472 implementations apply different heuristics, the result of 473 verification is no longer deterministic. As a result, [RFC6376] 474 asserts that use of the "z=" content, if present, can only be used 475 for diagnostic purposes. 477 In contrast, the proposal here enumerates a handful of specific 478 mutations known to be safe, and in common use, that are also 479 reversible, which means the Author's original content can be 480 unambiguously recovered and subjected to the usual signature 481 verification process even though the message has been legitimately 482 modified by a Mediator. 484 It does not take much imagination to conceive of a legitimate message 485 using the capability described here that fails some part of the 486 process. For example, the "footer" transformation does not account 487 for a footer block that itself contains a boundary marker, and so 488 reversing that transformation as described would produce a wrong 489 result. This is harmless, however, as the verifier then is no worse 490 off than it was before in that it still doesn't have the original 491 content, and thus operates as if none of this proposal was applied 492 (i.e., the original signature still fails). The proposal is only 493 incremental to what DKIM can provide when it actually does work to 494 recover original content. 496 It is expected that the definitions of the known transformations will 497 evolve over time as we gain community experience with what works. 499 As with DKIM itself, there are local policy decisions that can come 500 into play. Some DKIM verifiers insist that, for example, the Subject 501 field be included in the signed content, and will disregard a valid 502 DKIM signature where that is not the case. This requirement exceeds 503 what DKIM specifies, but verifiers have such discretion if they feel 504 it enhances user protection. So it is with this proposal: The fact 505 that an Author signature can validate after certain transformations 506 are reversed does not obligate the verifier to change its handling. 507 In particular, an operator may decide that reversal of certain 508 transformations is too fragile to render better handling, and it is 509 free to apply that discretion. 511 11. Security Considerations 513 11.1. Imported from DKIM 515 Section 8 of [RFC6376] discusses numerous security considerations 516 relevant to DKIM. Of particular interest here is Section 8.2, which 517 discusses concerns regarding signatures that sill verify in the 518 presence of added message content. 520 11.2. False Transformation Claims 522 Conceivably, some of these transformations or those registered in the 523 future could be computationally expensive or require non-trivial 524 ephemeral resource allocation (e.g., storage), especially for large 525 or complex messages. An attacker could send signatures in claiming 526 some or all of the known transformations on a message which a 527 participating verifier would then attempt to execute, presumably in 528 an attempt to recover original content, as a denial of service 529 attack. 531 There is little reason to believe that any given transformation might 532 be applied more than once, or that certain combinations have any 533 practical application (e.g., "footer" is unlikely to be useful when 534 combined with any of the MIME transformations). This experimental 535 document does not explicitly proscribe these, but implementers may 536 choose to detect such strange requests and disregard them. 538 12. IANA Considerations 540 12.1. DKIM Transformations Registry 542 IANA is requested to create a new registry in the DomainKeys 543 Identified Mail (DKIM) Parameters group called the "DKIM 544 Transformations Registry". This registry will enumerate known 545 reversible content transformations that might be made by Mediators to 546 messages bearing DKIM signatures. 548 Entries in this registry include all of the following: 550 Name: A simple name for a reversible message transformation; 552 Description: A terse description for the transformation; 554 Specification: A reference to a stable specification in which this 555 transformation and its reverse are clearly described; 557 Status: Must be one of: 559 * "active", meaning the transformation is in current use; 561 * "deprecated", meaning the transformation is not in current use. 563 An entry may be added or updated in this registry only when it meets 564 the requirements of the "Specification Required" rules found in 565 [RFC5226]. The Designated Expert will confirm that the referenced 566 specification is clear and complete, and that the transformation and 567 its reverse are not ambiguous. 569 The initial entries in this registry are as follows, all with status 570 "active": 572 add-part: Defined in Section 8 of this document. The simple 573 description is "append an extra text MIME part to a MIME-formatted 574 message". 576 footer: Defined in Section 6 of this document. The simple 577 description is "append a plain text footer to an unformatted 578 message". 580 mime-wrap: Defined in Section 9 of this document. The simple 581 description is "wrap a MIME-formatted message in a new multipart 582 layer". 584 mimeify: Defined in Section 7 of this document. The simple 585 description is "convert a non-MIME message to a MIME message". 587 subject: Defined in Section 5 of this document. The simple 588 description is "prepend a tag to the Subject field". 590 13. References 592 13.1. Normative References 594 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 595 Extensions (MIME) Part One: Format of Internet Message 596 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 597 . 599 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 600 IANA Considerations Section in RFCs", RFC 5226, 601 DOI 10.17487/RFC5226, May 2008, 602 . 604 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 605 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 606 RFC5234, January 2008, 607 . 609 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 610 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 611 RFC 6376, DOI 10.17487/RFC6376, September 2011, 612 . 614 13.2. Informative References 616 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 617 DOI 10.17487/RFC5598, July 2009, 618 . 620 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 621 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 622 September 2011, . 624 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 625 Message Authentication, Reporting, and Conformance 626 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 627 . 629 Appendix A. Example 631 This section presents a simple demonstration of the proposed 632 capability using the "subject" transformation described in Section 5. 633 Since only a header field is modified in that case, the example does 634 not include the message body. Also, only some fields are shown, and 635 base64 fields reflecting hashes contain mock values and may be 636 truncated as their values are not germane to this demonstration. 638 First, the header of the original message: 640 From: Alice Participant 641 To: IETF DKIM WG 642 Subject: I have an idea! 643 Date: Sun, 5 Jul 2020 13:26:23 -0700 (PDT) 644 DKIM-Signature: v=1; d=example.com; s=tolkein; a=rsa-sha256; 645 c=relaxed/simple; t=1593980799; 646 h=Date:From:To:Subject; 647 bh=5jBgWS5CnwV6HNp7irm1aMWW/VO0YHhvFIQldGZn7v0=; 648 b=Zaed9V18tBX789K2fpIG0H... 650 Alice sends this message with is fabulous DKIM idea to the list. The 651 list software receives it, prefixes a tag to its Subject field, and 652 then relays it to the list subscribers. The list software thus emits 653 the following mutated message: 655 From: Alice Participant 656 To: IETF DKIM WG 657 Subject: [ietf-dkim] I have an idea! 658 Date: Sun, 5 Jul 2020 13:26:23 -0700 (PDT) 659 DKIM-Signature: v=1; d=example.com; s=tolkein; a=rsa-sha256; 660 c=relaxed/simple; t=1593980799; 661 h=Date:From:To:Subject; 662 bh=5jBgWS5CnwV6HNp7irm1aMWW/VO0YHhvFIQldGZn7v0=; 663 b=Zaed9V18tBX789K2fpIG0H... 664 DKIM-Signature: v=1; d=ietf.example.org; s=rabbit; a=rsa-sha256; 665 c=relaxed/simple; t=1593980802; tf=subject; 666 h=Date:From:To:Subject; 667 bh=cwpuQruv+3/b493YEQBqBLS8UgNGP+rQ6fuhJ2csvdQ=; 668 b=l0+hCymcA93hq6Pex2OsCFfdDjomrBUe7JVRSfmJN... 670 Bob is subscribed to this list, so it arrives at his Mail Transfer 671 Agent (MTA) which has a DKIM verifier participating in this 672 experiment. Were it to attempt to validate the "example.com" 673 signature, it would fail because the Subject field fed to the signing 674 algorithm is not the same as that fed to the verifying algorithm. 676 However, the "ietf.example.org" tag does verify. It furthermore 677 contains the "tf" tag indicating a Subject field mutation occurred. 678 The verifier thus re-attempts the "example.com" signature 679 verification after having applied the reverse of the Subject field 680 mutation. In so doing, the hash algorithm at the verifier now 681 receives the same content that was originally passed to the signing 682 algorithm at "example.com", which means the Author signature 683 validation succeeds. This fact can then be used to augment whatever 684 local policy decision might otherwise have been made in the absence 685 of a valid author domain signature. 687 Appendix B. Acknowledgements 689 The original team developing this concept included Michael Adkins and 690 Wez Furlong. 692 The author wishes to acknowledge (names) for their comments during 693 the development of this document. 695 Appendix C. To-Do List 697 o Experimentally implement at least the "subject" and "footer" 698 transformations. 700 Appendix D. Change Log 702 02: Add a simple example. Mention verifier handling discretion. 703 Some language tidying. 705 01: Resurrection; add "subject" and "footer", and generally more 706 prose. 708 00: Initial revision. 710 Author's Address 712 Murray S. Kucherawy 714 EMail: superuser@gmail.com