idnits 2.17.1 draft-melnikov-smime-header-signing-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 date (April 3, 2015) is 3282 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 April 3, 2015 5 Expires: October 5, 2015 7 Considerations for protecting Email header with S/MIME 8 draft-melnikov-smime-header-signing-01 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 http://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 October 5, 2015. 34 Copyright Notice 36 Copyright (c) 2015 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 (http://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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 7.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 S/MIME [RFC5751] is typically used to protect (sign and/on encrypt) 66 Email message body parts, but not header of corresponding Email 67 messages. Header fields may contain confidential information or 68 information whose validity need protecting from disclosure or 69 modification. [RFC5751] describes how to protect the Email message 70 header [RFC5322], by wrapping the message inside a message/rfc822 71 container [RFC2045]: 73 In order to protect outer, non-content-related message header 74 fields (for instance, the "Subject", "To", "From", and "Cc" 75 fields), the sending client MAY wrap a full MIME message in a 76 message/rfc822 wrapper in order to apply S/MIME security services 77 to these header fields. It is up to the receiving client to 78 decide how to present this "inner" header along with the 79 unprotected "outer" header. 81 When an S/MIME message is received, if the top-level protected 82 MIME entity has a Content-Type of message/rfc822, it can be 83 assumed that the intent was to provide header protection. This 84 entity SHOULD be presented as the top-level message, taking into 85 account header merging issues as previously discussed. 87 While the above advice helps in protecting message header fields, it 88 doesn't provide enough guidance on what information should and should 89 not be included in outer (unprotected) header and how information 90 from outer and inner headers should be presented to users. This 91 document describes best UI and other practices for handling of 92 messages wrapped inside message/rfc822 body parts. The goal of this 93 document is to improve interoperability and minimize damage caused by 94 possible differences between inner and outer headers. 96 2. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Recommendations for handling of S/MIME protected header 104 When generating S/MIME messages which protect header fields by 105 wrapping a message inside message/rfc822 wrapper: 107 1. If a header field is being encrypted because it is sensitive, its 108 value MUST NOT be included in the outer header. If the header 109 field is mandatory according to RFC 5322, a stub value (or a 110 value indicating that the outer value is not to be used) is to be 111 included. 113 2. The outer header SHOULD be minimal in order to avoid disclosure 114 of confidential information. It is recommended that the outer 115 header only contains "Date" (set to the same value as in the 116 inner header, or, if the Date value is also sensitive, to Monday 117 9am of the same week), possibly "Subject" and "To"/"Bcc" header 118 fields. But note that having key header fields duplicated in the 119 outer header is convenient for many message stores (e.g. IMAP) 120 and clients that can't decode S/MIME encrypted messages. In 121 particular, Subject/To/Cc/Bcc information is returned in IMAP 122 ENVELOPE FETCH data item [RFC3501], which is frequently used by 123 IMAP clients in order to avoid parsing message header. 125 3. Note that the above recommendations can also affect antispam 126 processing. 128 4. The "Subject" header field value of the outer header SHOULD 129 either be identical to the inner "Subject" header field value, or 130 contain a clear indication that the outer value is not to be used 131 for display (the inner header field value would contain the true 132 value). 134 Note that recommendations listed above only apply to non MIME header 135 fields (header fields with names not starting with "Content-" 136 prefix). 138 When displaying S/MIME messages which protect header fields by 139 wrapping a message inside message/rfc822 wrapper: 141 1. The outer headers might be tampered with, so a receiving client 142 SHOULD ignore them. If a header field is present in the inner 143 header, only the inner header field value MUST be displayed (and 144 the corresponding outer value must be ignored). If a particular 145 header field is only present in the outer header, it MAY be 146 ignored (not displayed) or it MAY be displayed with a clear 147 indicator that it is not trustworthy(*). 149 (*) - the latter case only applies if the header field is not 150 protected is some other way, for example by DKIM. 152 4. New Content-Type header field parameter: forwarded 154 This document defines a new Content-Type header field parameter 155 [RFC2045] with name "forwarded". The parameter value is case- 156 insensitive and can be either "yes" or "no". (The default value 157 being "yes"). The parameter is only meaningful with media type 158 "message/rfc822" when used within S/MIME encrypted body parts. The 159 value "yes" means that the message nested inside message/rfc822 is a 160 forwarded message and not a construct created solely to protect the 161 inner header. 163 Instructions in [RFC5751] describing how to protect the Email message 164 header [RFC5322], by wrapping the message inside a message/rfc822 165 container [RFC2045] are thus updated to read: 167 In order to protect outer, non-content-related message header 168 fields (for instance, the "Subject", "To", "From", and "Cc" 169 fields), the sending client MAY wrap a full MIME message in a 170 message/rfc822 wrapper in order to apply S/MIME security services 171 to these header fields. It is up to the receiving client to 172 decide how to present this "inner" header along with the 173 unprotected "outer" header. 175 When an S/MIME message is received, if the top-level protected 176 MIME entity has a Content-Type of message/rfc822 without the 177 "forwarded" parameter or with the "forwarded" parameter set to 178 "no", it can be assumed that the intent was to provide header 179 protection. This entity SHOULD be presented as the top-level 180 message, taking into account header merging issues as previously 181 discussed. 183 5. IANA Considerations 185 This document requests no action from IANA. RFC Editor should delete 186 this section before publication. 188 6. Security Considerations 190 This document talks about UI considerations, including security 191 considerations, when processing wrapped message/rfc822 messages 192 protecting header fields. One of the goals of this document is to 193 specify UI for displaying such messages which is less confusing/ 194 misleading and thus more secure. 196 The document is not defining new protocol, so it doesn't create any 197 new security concerns not already covered by S/MIME [RFC5751], MIME 198 [RFC2045] and Email [RFC5322] in general. 200 7. References 202 7.1. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 208 Extensions (MIME) Part One: Format of Internet Message 209 Bodies", RFC 2045, November 1996. 211 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 212 October 2008. 214 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 215 Mail Extensions (S/MIME) Version 3.2 Message 216 Specification", RFC 5751, January 2010. 218 7.2. Informative References 220 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 221 4rev1", RFC 3501, March 2003. 223 Appendix A. Acknowledgements 225 Thank you to Steve Kille and David Wilson for suggestions, comments 226 and corrections on this document. 228 David Wilson came up with the idea of defining a new Content-Type 229 header field parameter to distinguish forwarded messages from inner 230 header field protection constructs. 232 Author's Address 234 Alexey Melnikov 235 Isode Ltd 236 14 Castle Mews 237 Hampton, Middlesex TW12 2NP 238 UK 240 EMail: Alexey.Melnikov@isode.com