idnits 2.17.1 draft-melnikov-smime-header-signing-05.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 (October 1, 2017) is 2391 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) 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 A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational October 1, 2017 5 Expires: April 4, 2018 7 Considerations for protecting Email header with S/MIME 8 draft-melnikov-smime-header-signing-05 10 Abstract 12 This document describes best practices for handling of Email header 13 protected by S/MIME. It also adds a new Content-Type parameter to 14 help distinguish an S/MIME protected forwarded message from an S/MIME 15 construct protecting message header. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 4, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. Recommendations for handling of S/MIME protected header . . . 3 54 4. New Content-Type header field parameter: forwarded . . . . . 4 55 5. Example message with S/MIME header protection . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 8.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 S/MIME [RFC5751] is typically used to protect (sign and/or encrypt) 67 Email message body parts, but not header of corresponding Email 68 messages. Header fields may contain confidential information or 69 information whose validity need protecting from disclosure or 70 modification. [RFC5751] describes how to protect the Email message 71 header [RFC5322], by wrapping the message inside a message/rfc822 72 container [RFC2045]: 74 In order to protect outer, non-content-related message header 75 fields (for instance, the "Subject", "To", "From", and "Cc" 76 fields), the sending client MAY wrap a full MIME message in a 77 message/rfc822 wrapper in order to apply S/MIME security services 78 to these header fields. It is up to the receiving client to 79 decide how to present this "inner" header along with the 80 unprotected "outer" header. 82 When an S/MIME message is received, if the top-level protected 83 MIME entity has a Content-Type of message/rfc822, it can be 84 assumed that the intent was to provide header protection. This 85 entity SHOULD be presented as the top-level message, taking into 86 account header merging issues as previously discussed. 88 While the above advice helps in protecting message header fields, it 89 doesn't provide enough guidance on what information should and should 90 not be included in outer (unprotected) header and how information 91 from outer and inner headers should be presented to users. This 92 document describes best UI and other practices for handling of 93 messages wrapped inside message/rfc822 body parts. The goal of this 94 document is to improve interoperability and minimize damage caused by 95 possible differences between inner and outer headers. 97 2. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. Recommendations for handling of S/MIME protected header 105 When generating S/MIME messages which protect header fields by 106 wrapping a message inside message/rfc822 wrapper: 108 1. If a header field is being encrypted because it is sensitive, its 109 true value MUST NOT be included in the outer header. If the 110 header field is mandatory according to RFC 5322, a stub value (or 111 a value indicating that the outer value is not to be used) is to 112 be included. 114 2. The outer header SHOULD be minimal in order to avoid disclosure 115 of confidential information. It is recommended that the outer 116 header only contains "Date" (set to the same value as in the 117 inner header, or, if the Date value is also sensitive, to Monday 118 9am of the same week), possibly "Subject" and "To"/"Bcc" header 119 fields. In particular, Keywords, In-Reply-To and References 120 header fields SHOULD NOT be included in the outer header; "To" 121 and "Cc" header fields should be omitted and replaced with "Bcc: 122 undisclosed-recipients;". 124 But note that having key header fields duplicated in the outer 125 header is convenient for many message stores (e.g. IMAP) and 126 clients that can't decode S/MIME encrypted messages. In 127 particular, Subject/To/Cc/Bcc/Date header field values are 128 returned in IMAP ENVELOPE FETCH data item [RFC3501], which is 129 frequently used by IMAP clients in order to avoid parsing message 130 header. 132 3. The "Subject" header field value of the outer header SHOULD 133 either be identical to the inner "Subject" header field value, or 134 contain a clear indication that the outer value is not to be used 135 for display (the inner header field value would contain the true 136 value). 138 Note that recommendations listed above only apply to non MIME header 139 fields (header fields with names not starting with "Content-" 140 prefix). 142 Note that the above recommendations can also negatively affect 143 antispam processing. 145 When displaying S/MIME messages which protect header fields by 146 wrapping a message inside message/rfc822 wrapper: 148 1. The outer headers might be tampered with, so a receiving client 149 SHOULD ignore them, unless they are protected in some other 150 way(*). If a header field is present in the inner header, only 151 the inner header field value MUST be displayed (and the 152 corresponding outer value must be ignored). If a particular 153 header field is only present in the outer header, it MAY be 154 ignored (not displayed) or it MAY be displayed with a clear 155 indicator that it is not trustworthy(*). 157 (*) - this only applies if the header field is not protected is 158 some other way, for example with a DKIM signature that validates 159 and is trusted. 161 4. New Content-Type header field parameter: forwarded 163 This document defines a new Content-Type header field parameter 164 [RFC2045] with name "forwarded". The parameter value is case- 165 insensitive and can be either "yes" or "no". (The default value 166 being "yes"). The parameter is only meaningful with media type 167 "message/rfc822" and "message/global" [RFC6532] when used within 168 S/MIME encrypted body parts. The value "yes" means that the message 169 nested inside message/rfc822 is a forwarded message and not a 170 construct created solely to protect the inner header. 172 Instructions in [RFC5751] describing how to protect the Email message 173 header [RFC5322], by wrapping the message inside a message/rfc822 174 container [RFC2045] are thus updated to read: 176 In order to protect outer, non-content-related message header 177 fields (for instance, the "Subject", "To", "From", and "Cc" 178 fields), the sending client MAY wrap a full MIME message in a 179 message/rfc822 wrapper in order to apply S/MIME security services 180 to these header fields. It is up to the receiving client to 181 decide how to present this "inner" header along with the 182 unprotected "outer" header. 184 When an S/MIME message is received, if the top-level protected 185 MIME entity has a Content-Type of message/rfc822 or message/global 186 without the "forwarded" parameter or with the "forwarded" 187 parameter set to "no", it can be assumed that the intent was to 188 provide header protection. This entity SHOULD be presented as the 189 top-level message, taking into account header merging issues as 190 previously discussed. 192 5. Example message with S/MIME header protection 194 The following example demonstrates a message generated to protect 195 original message header. For example, this will be the first body 196 part of a multipart/signed message or the payload of the application/ 197 pkcs7-mime body part. 199 Content-Type: message/rfc822; forwarded=no 201 Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 202 From: "Alexey Melnikov" 203 Message-ID: 204 MIME-Version: 1.0 205 MMHS-Primary-Precedence: 3 206 Subject: Secret meeting at my place 207 To: somebody@example.net 208 X-Mailer: Isode Harrier Web Server 209 content-type: text/plain; charset=us-ascii 211 This is a secret message worth protecting. 213 [[CREF1: Extend the example to show different inner and outer header 214 fields and clarify what should be displayed?]] 216 6. IANA Considerations 218 This document requests no action from IANA. RFC Editor should delete 219 this section before publication. 221 7. Security Considerations 223 This document talks about UI considerations, including security 224 considerations, when processing wrapped message/rfc822 messages 225 protecting header fields. One of the goals of this document is to 226 specify UI for displaying such messages which is less confusing/ 227 misleading and thus more secure. 229 The document is not defining new protocol, so it doesn't create any 230 new security concerns not already covered by S/MIME [RFC5751], MIME 231 [RFC2045] and Email [RFC5322] in general. 233 8. References 234 8.1. Normative References 236 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 237 Extensions (MIME) Part One: Format of Internet Message 238 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 239 . 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 247 DOI 10.17487/RFC5322, October 2008, 248 . 250 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 251 Mail Extensions (S/MIME) Version 3.2 Message 252 Specification", RFC 5751, DOI 10.17487/RFC5751, January 253 2010, . 255 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 256 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 257 2012, . 259 8.2. Informative References 261 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 262 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 263 . 265 Appendix A. Acknowledgements 267 Thank you to Wei Chuang, Steve Kille, David Wilson and Robert 268 Williams for suggestions, comments and corrections on this document. 269 Some ideas were also taken from Daniel Kahn Gillmor's email on the 270 OpenPGP mailing list. 272 David Wilson came up with the idea of defining a new Content-Type 273 header field parameter to distinguish forwarded messages from inner 274 header field protection constructs. 276 Author's Address 278 Alexey Melnikov 279 Isode Ltd 280 14 Castle Mews 281 Hampton, Middlesex TW12 2NP 282 UK 284 EMail: Alexey.Melnikov@isode.com