idnits 2.17.1 draft-vanrein-dkim-lenient-00.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 156: '...ed-Content headers MUST be inserted on...' RFC 2119 keyword, line 157: '...the message, and MUST NOT be reordered...' RFC 2119 keyword, line 199: '...tent-Disposition SHOULD be included; o...' RFC 2119 keyword, line 200: '...ransfer-Encoding SHOULD NOT be include...' RFC 2119 keyword, line 206: '...dary, whose contents MUST be set to an...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2017) is 2398 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft ARPA2.net 4 Intended status: Standards Track September 25, 2017 5 Expires: March 29, 2018 7 Lenient DKIM 8 draft-vanrein-dkim-lenient-00 10 Abstract 12 DKIM is a framework for signed messages, especially for email. While 13 in transit, changes are sometimes made, and these break the DKIM- 14 Signature. This specification makes DKIM more lenient, without 15 changes to its core. It adds leniency towards MIME body rewrites, 16 removal of alternatives and annotation with bits of text. The 17 intention is to allow these changes such that they can be clearly 18 shown to the user, while indicating that the remainder of the 19 signedmessage is still in tact. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 29, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Annotating DKIM-Signed-Content . . . . . . . . . . . . . . . 3 57 2.1. Header Definition . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Signing MIME bodies . . . . . . . . . . . . . . . . . . . 5 59 3. Canonicalisation for MIME Content . . . . . . . . . . . . . . 5 60 3.1. MIME headers . . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. MIME body parts . . . . . . . . . . . . . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 DKIM standardises a header that signs content and headers of (email) 70 messages. This is a practical system to validate (the origin of) a 71 message to not have changed; unfortunely however, it breaks on a few 72 patterns of communication that are in common use xref- 73 target-"RFCnnnn". As a result, it is difficult to assign the full 74 weight of evidence that DKIM could otherwise provide. 76 DKIM signs content based on their wire format, which may include a 77 transfer-encoding when the MIME extensions are used. MTAs may have 78 to alter this transfer-encoding to accommodate a downgrade of 79 communication capabilities, and are therefore permitted to do so, but 80 this is not compatible with current DKIM. This specification 81 introduces a new canonicalisation algorithm to remedy this problem, 82 based on fixating the binary content of a MIME body part. 84 Another common practice is the introduction of extra text in the 85 Subject header of an email, or in the body or body parts. As a 86 general principle, it need not be problemtic to introduce extra data 87 to an email, as long as this is clearly shown in the MUA. Given that 88 email is usually rendered in a manner that has information fields in 89 clearly distinct graphical framing, it should be possible for a MUA 90 to unambiguously mark any additions made. This specification 91 introduces a manner of locating the parts of a message that were not 92 modified since it was signed, and leaves it to the MUA to decide on a 93 method of distinct rendering for original and modified parts. The 94 same mechanisms may be useful for MTAs for distinguishing common 95 patterns from abusive ones. When unsupportive or incapable, a MUA or 96 MTA is always free to not incorporate DKIM's confirmations of message 97 content. 99 A more debatable practice is the removal of complete MIME 100 attachments. This is sometimes done for content in an undesirable 101 format, usually for operational considerations. Such removals can be 102 clearly marked, and it is up to the MUA whether to accept the 103 removal. When one part of an originally sent multipart/alternative 104 is removed, it may not be as bad as when the composition is altered, 105 as would be the case with other multipart types, such as multipart/ 106 form-data. 108 The general handling of a MIME multipart/* message body involves a 109 number of independently encoded body parts. When this Content-Type 110 is used, a separate DKIM-Signature will be made on each of the body 111 parts, and a dedicated canonicalisation method will be used to 112 compose the parts. This will list the hashes of the various body 113 parts, thus enabling the detection of a removed part. 115 2. Annotating DKIM-Signed-Content 117 When changes are made to parts of the message, be it to headers or 118 body, then a DKIM-Signature is invalidated. Although this is a clear 119 sign of modification, it is not always a sign of a rogue change. 120 Ideally, the changed content would be presented to the user, but in 121 such a manner that original content can be easily distinguished from 122 changed content. When the changed message is subsequently signed by 123 an intermediate mailer, it is also clear where any concerns about the 124 change should be redirected, which is helpful for reputation 125 management. 127 The DKIM-Signed-Content header can be inserted after a DKIM- 128 Signature, possibly at the origin or at a later stage of the message, 129 to mark parts of the message that are incorporated into the signature 130 as a whole header, or as a whole body. It may in turn be 131 incorporated into a DKIM-Signature of a modified-forwarding party 132 such as an email list, where the new DKIM-Signature implies taking 133 responsibility over the changes made locally. But even when this is 134 not done, the DKIM-Signed-Content header allows a receiving MTA, MUA 135 or user to learn standard patterns of change by such intermediates, 136 and hopefully trigger alarms after deviations from a pattern. 138 To detect extra text, the DKIM-Signed-Content header describes the 139 range that was originally signed, describing the text in canonical 140 representation through its size, a rolling checksum and a secure 141 hash. The size and rolling checksum can be used to quickly pass 142 through a text in search of the original text; the secure hash is 143 then used to validate that it is indeed a good match. 145 Originators could insert DKIM-Signed-Content headers before or after 146 inserting the DKIM-Signature header to allow non-compliant forwarders 147 to be easily recognised. Forwarders who add their own DKIM-Signature 148 on modified content are advised to retain the existing ones, validate 149 or remove any DKIM-Signed-Content headers inserted after the last 150 DKIM-Signature, add any missing DKIM-Signed-Content headers over what 151 will be modified, then make the desired modifications and then insert 152 the new DKIM-Signature header. This procedure ensures that the 153 forwarder only takes responsibility over their own work, which helps 154 in building their reputation. 156 DKIM-Signature and DKIM-Signed-Content headers MUST be inserted on 157 top of the message, and MUST NOT be reordered in transit. This is a 158 common and reasonable requirement for current messaging systems. 160 The DKIM-Signed-Content header works for complete headers or for 161 complete bodies, and will fail to work when content is being removed. 162 This is to protect users from information being held back; the one 163 exception is in the handling of multipart/alternative, defined below. 165 2.1. Header Definition 167 The DKIM-Signed-Content header consists of one or more sets of the 168 following four components, with whitespace to separate components: 169 (1) the path to the content; (2) the decimal notation for the length 170 in bytes; (3) the hexadecimal notation for a rolling hash; (4) the 171 secure hash of the content. 173 The path to the content is either a header name or the special word 174 "Body" to notify the message body. When multiple instances exist, an 175 optional extension is permitted, namely a colon and a decimal 176 sequence number, counting from 0. Headers count in the order of 177 insertion, so in the opposite order of their occurrence in the 178 message. Bodies count in the order in which they occur in th 179 message, but this is only meaningful for multipart MIME-types. 180 TODO:ALT:0 is the last value inserted before the DKIM-Signature; no 181 going back. TODO:EXT:Allow header:index:header:index:... 183 The values that follow all apply to the canonical form of the 184 information, be it a header or body, as specified in the "c" 185 parameter of the DKIM-Signature that was last inserted into the 186 message. 188 The rolling hash is TODO:AS_IN_RSYNC? cyclic polynomials looks best. 189 Implementation note: either have the full message in memory or have 190 to files open on it for reading. 192 The secure hash matches the representation and algorithm of the "bh" 193 field in the related DKIM-Signature. 195 2.2. Signing MIME bodies 197 When a body with MIME content is signed, then more headers should be 198 considered for inclusion in the DKIM-Signature; notably, MIME- 199 Version, Content-Type, Content-Disposition SHOULD be included; on the 200 other hand, Content-Transfer-Encoding SHOULD NOT be included when the 201 intention is to support changes to the transfer encoding. When 202 headers are absent, their inclusion into the DKIM-Signature header 203 list disables later-on addition of these headers. TODO:CHECK 205 Special processing is required for the Content-Type header; it 206 includes a field named boundary, whose contents MUST be set to an 207 empty string, included in double quotes, before computing the header 208 checksum. This assures that changes to the boundary tag are 209 permitted while the message moves between MTAs. TODO:ALT: Move this 210 parameter to the end of the header and take it out from the DKIM- 211 Signed-Content as well as the DKIM-Signature; this requires MTAs and 212 MUAs to recognise this missing information as correctly absent. 214 All body parts of a multipart MIME message SHOULD have a DKIM- 215 Signature inserted. In this case, the Content-Type, Content- 216 Disposition and Content-ID headers SHOULD be included, even when they 217 are not presented as headers, in which case they could not be added 218 later. Note that the remarks made above for the boundary tag in a 219 Content-Type header may apply recursively. 221 When signing a multipart message, a DKIM-Signed-Content header SHOULD 222 include the DKIM-Signature headers of the directly subordinate body 223 parts. Indirect subordinates are included recursively by these 224 nested DKIM-Signature headers. 226 This practice enables the detection of removed as well as added body 227 parts. A common example is the removal of a text/html form from 228 multipart/alternative, so as to leave the text/plain form. This may 229 be tolerated on account of the semantics of multipart/alternative 230 messages. 232 3. Canonicalisation for MIME Content 234 MIME messages require special handling. The descriptions below 235 define how headers and bodies are canonicalised for MIME handling. 236 When a message has a MIME-Version header, it MAY want ot use c=mime/ 237 mime in its DKIM-Signature headers. 239 This is an extension to the version of DKIM that is currently in use, 240 but it is not a change to the header format, merely a matter of new 241 canonicalisation rules and handling for contained body parts. This 242 means that no new version number is defined for DKIM. The changes 243 may however lead to interpretation problems in older software. To 244 serve these somewhat, it is possible for DKIM signers to add not only 245 a DKIM-Signature with c=mime/mime, but also with other 246 canonicalisation mechanisms. It is advised to plan a final date for 247 any such policy. 249 3.1. MIME headers 251 Header canonicalisation for MIME headers is a modified form of the 252 relaxed algorithm. Its added function is to change any boundary tag 253 in a Content-Type header to an empty string, denoted as two double 254 quotes. 256 3.2. MIME body parts 258 When an MTA carries a binary message over a degraded link, it may 259 need to change the encoding of the message body. The simple and 260 relaxed canonicalisation algorithms both relate to the wire format of 261 the message and will break on such valid changes of form. For MIME 262 body parts however, this wire format is representative of an exactly 263 reproduced binary format, which can serve as a canonical format for 264 these body parts. 266 The body canonicalisation algorithm "mime" is used to reduce the wire 267 format of a MIME message body to the binary content that it 268 represents, before applying hashing and signing algorithms. This 269 should make it neutral to changes to the transfer encoding. Note 270 that it is vital that the Message-Transfer-Encoding header MUST NOT 271 be included in the header list when the "content" algorithm is used. 273 The "mime" algorithm MUST NOT be used on multipart messages. For 274 those, an zero-byte body is used with headers including a DKIM- 275 Signed-Content header that references that various body parts 276 individually. 278 Some MIME body parts include an URI reference, and it is possible for 279 an MDA or MUA to replace a body part with such a reference to an 280 external store. In such cases, a DKIM-Signature on the body part is 281 bound to fail; it would however serve to validate the downloaded 282 content together with the descriptive headers that are signed along 283 with it. This means that components of the mail system that replace 284 a body part by an URI reference should try to retain any DKIM- 285 Signature header. Especially when a bh field is included, it would 286 be easy to verify a downloaded body part. 288 4. IANA Considerations 290 TODO:REGISTER:HEADER:DKIM-SIGNED-CONTENT 292 TODO:REGISTER:DKIMCANONALG:CONTENT 294 5. Security Considerations 296 TODO: Parts before/after MIME body parts 298 TODO: Modified MIME separators that also appear in body parts. 300 Appendix A. Acknowledgements 302 Author's Address 304 Rick van Rein 305 ARPA2.net 306 Haarlebrink 5 307 Enschede, Overijssel 7544 WP 308 The Netherlands 310 Email: rick@openfortress.nl