p≡p I-Ds (IETF Internet-Drafts)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1288 lines
43 KiB

  1. Network Working Group B. Hoeneisen
  2. Internet-Draft pEp Foundation
  3. Intended status: Informational A. Melnikov
  4. Expires: December 28, 2020 Isode Ltd
  5. June 26, 2020
  6. Header Protection for S/MIME
  7. draft-ietf-lamps-header-protection-00
  8. Abstract
  9. Privacy and security issues with email header protection in S/MIME
  10. have been identified for some time. However, the desire to fix these
  11. issues has only recently been expressed in the IETF LAMPS Working
  12. Group. The existing S/MIME specification is to be updated regarding
  13. header protection.
  14. This document describes the problem statement, generic use cases, and
  15. the S/MIME specification for header protection.
  16. Status of This Memo
  17. This Internet-Draft is submitted in full conformance with the
  18. provisions of BCP 78 and BCP 79.
  19. Internet-Drafts are working documents of the Internet Engineering
  20. Task Force (IETF). Note that other groups may also distribute
  21. working documents as Internet-Drafts. The list of current Internet-
  22. Drafts is at https://datatracker.ietf.org/drafts/current/.
  23. Internet-Drafts are draft documents valid for a maximum of six months
  24. and may be updated, replaced, or obsoleted by other documents at any
  25. time. It is inappropriate to use Internet-Drafts as reference
  26. material or to cite them other than as "work in progress."
  27. This Internet-Draft will expire on December 28, 2020.
  28. Copyright Notice
  29. Copyright (c) 2020 IETF Trust and the persons identified as the
  30. document authors. All rights reserved.
  31. This document is subject to BCP 78 and the IETF Trust's Legal
  32. Provisions Relating to IETF Documents
  33. (https://trustee.ietf.org/license-info) in effect on the date of
  34. publication of this document. Please review these documents
  35. carefully, as they describe your rights and restrictions with respect
  36. Hoeneisen & Melnikov Expires December 28, 2020 [Page 1]
  37. Internet-Draft Header Protection S/MIME June 2020
  38. to this document. Code Components extracted from this document must
  39. include Simplified BSD License text as described in Section 4.e of
  40. the Trust Legal Provisions and are provided without warranty as
  41. described in the Simplified BSD License.
  42. Table of Contents
  43. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
  44. 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
  45. 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  46. 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
  47. 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6
  48. 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
  49. 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6
  50. 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 6
  51. 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  52. 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 7
  53. 3.1.1. Main Case for Header Protection . . . . . . . . . . . 7
  54. 3.1.2. Backward Compatibility . . . . . . . . . . . . . . . 7
  55. 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 7
  56. 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
  57. 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 8
  58. 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 8
  59. 4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 13
  60. 4.1.3. Wrapper . . . . . . . . . . . . . . . . . . . . . . . 13
  61. 4.1.4. Outer Message Header Fields . . . . . . . . . . . . . 13
  62. 4.1.5. Sending Side Message Processing . . . . . . . . . . . 15
  63. 4.1.6. Receiving Side Message Processing . . . . . . . . . . 16
  64. 4.1.7. Header Field Flow . . . . . . . . . . . . . . . . . . 17
  65. 4.2. Backward Compatibility Use Case . . . . . . . . . . . . . 18
  66. 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
  67. 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
  68. 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
  69. 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
  70. 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
  71. 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
  72. 9.2. Informative References . . . . . . . . . . . . . . . . . 20
  73. 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
  74. Appendix A. Additional information . . . . . . . . . . . . . . . 21
  75. A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 21
  76. Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 22
  77. Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 22
  78. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
  79. Hoeneisen & Melnikov Expires December 28, 2020 [Page 2]
  80. Internet-Draft Header Protection S/MIME June 2020
  81. 1. Introduction
  82. A range of protocols for the protection of electronic mail (email)
  83. exist, which allow to assess the authenticity and integrity of the
  84. email headers section or selected header fields (HF) from the domain-
  85. level perspective, specifically DomainKeys Identified Mail (DKIM)
  86. [RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
  87. based Message Authentication, Reporting, and Conformance (DMARC)
  88. [RFC7489]. These protocols, while essential to responding to a range
  89. of attacks on email, do not offer (full) end-to-end protection to the
  90. header section and are not capable of providing privacy for the
  91. information contained therein.
  92. The need for means of Data Minimization, which includes data
  93. spareness and hiding all technically concealable information whenever
  94. possible, has grown in importance over the past several years.
  95. A standard for end-to-end protection of the email header section
  96. exists for S/MIME version 3.1 and later. (cf. [RFC8551]):
  97. In order to protect outer, non-content-related message header
  98. fields (for instance, the "Subject", "To", "From", and "Cc"
  99. fields), the sending client MAY wrap a full MIME message in a
  100. message/RFC822 wrapper in order to apply S/MIME security services
  101. to these header fields.
  102. No mechanism for header protection (HP) has been standardized for
  103. PGP/MIME (Pretty Good Privacy) [RFC3156] yet.
  104. Several varying implementations of end-to-end protections for email
  105. header sections exist, though the total number of such
  106. implementations appears to be rather low.
  107. Some LAMPS WG participants expressed the opinion that whatever
  108. mechanism will be chosen, it should not be limited to S/MIME, but
  109. also applicable to PGP/MIME.
  110. This document describes the problem statement (Section 2), generic
  111. use cases (Section 3) and the specification for Header Protection
  112. (Section 4).
  113. [I-D.ietf-lamps-header-protection-requirements] defines the
  114. requirements that this specification is based on.
  115. This document is in early draft state and contains a proposal to base
  116. the upcoming discussions on. In any case, the final solution is to
  117. be determined by the IETF LAMPS WG.
  118. Hoeneisen & Melnikov Expires December 28, 2020 [Page 3]
  119. Internet-Draft Header Protection S/MIME June 2020
  120. 1.1. Requirements Language
  121. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  122. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  123. document are to be interpreted as described in [RFC2119].
  124. 1.2. Terms
  125. The following terms are defined for the scope of this document:
  126. o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
  127. form of active wiretapping attack in which the attacker intercepts
  128. and selectively modifies communicated data to masquerade as one or
  129. more of the entities involved in a communication association."
  130. o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.
  131. [RFC8551])
  132. o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156])
  133. o Message: An Email Message consisting of header fields
  134. (collectively called "the Header Section of the message")
  135. followed, optionally, by a Body; cf. [RFC5322].
  136. o Transport: The entity taking care of the transport of a Message
  137. towards the receiver or from the sender. The Transport on the
  138. sending side typically determines the destination recipients by
  139. reading the To, Cc and Bcc Header Fields (of the Outer Message).
  140. The Transport is typically implemented by an MTA (Mail Transfer
  141. Agent).
  142. o Header Field (HF): cf. [RFC5322] Header Fields are lines beginning
  143. with a field name, followed by a colon (":"), followed by a field
  144. body (value), and terminated by CRLF; cf. [RFC5322].
  145. Note: To avoid ambiguity, this document does not use the terms
  146. "Header" or "Headers" in isolation, but instead always uses
  147. "Header Field" to refer to the individual field and "Header
  148. Section" to refer to the entire collection; cf. [RFC5322].
  149. o Header Section (HS): The Header Section is a sequence of lines of
  150. characters with special syntax as defined in [RFC5322]. It is the
  151. (top) section of a message containing the Header Fields.
  152. o Body: The Body is simply a sequence of characters that follows the
  153. Header Section and is separated from the Header Section by an
  154. empty line (i.e., a line with nothing preceding the CRLF); cf
  155. [RFC5322]. It is the (bottom) section of Message containing the
  156. Hoeneisen & Melnikov Expires December 28, 2020 [Page 4]
  157. Internet-Draft Header Protection S/MIME June 2020
  158. payload of a Message. Typically, the Body consists of a
  159. (multipart) MIME [RFC2045] construct.
  160. o MIME Header Fields: Header Fields describing the MIME structure of
  161. its body as defined in [RFC2045].
  162. o MIME Header Section (part): The collection of MIME Header Fields.
  163. "MIME Header Section" refers to a Header Sections that contains
  164. only MIME Header Fields, whereas "MIME Header Section part" refers
  165. to the MIME Header Fields of a Header Section that - in addition
  166. to MIME Header Fields - also contains non-MIME Header Fields.
  167. o Header Protection (HP): cryptographic protection of email Header
  168. Sections (or parts of it) for signatures and/or encryption
  169. o Protection Levels (PL): One of 'signature and encryption',
  170. 'signature only' or 'encryption only' (cf. Section 3.2)
  171. o Original Message (OrigM): The message to be protected before any
  172. protection related processing has been applied on the sending
  173. side.
  174. o Inner Message (InnerM): The message to be protected, shortly
  175. before wrapping and protection measures are applied to on the
  176. sending side or the message shortly after decryption and
  177. unwrapping has been applied to on the receiving side respectively.
  178. Typically, the Inner Message is in clear text. The Inner Message
  179. is a subset of (or the same as) the Original Message. The Inner
  180. Message must be the same on the sending and the receiving side.
  181. o Outer Message (OuterM): The Message as handed over to the
  182. Transport or received from the Transport respectively. The Outer
  183. Message normally differs on the sending and the receiving side
  184. (e.g. new Header Fields are added by intermediary nodes).
  185. o Receiving User Facing Message (RUFM): The message used for
  186. rendering at the receiving side after the Outer Message Header
  187. Section has been merged with the Inner Message Header Section.
  188. o Essential Header Fields (EHF): The Header Fields an Outer Message
  189. Header Section SHOULD contain at least; cf. Section 4.1.4.
  190. o Protected: Protected refers to the parts of a message where
  191. protection measures of any Protection Levels have been applied to.
  192. o Protected Message: A message that protection measures of any
  193. Protection Levels have been applied to.
  194. Hoeneisen & Melnikov Expires December 28, 2020 [Page 5]
  195. Internet-Draft Header Protection S/MIME June 2020
  196. o Unprotected: Unprotected refers to the parts of a message where no
  197. protection measures of any Protection Levels have been applied to.
  198. o Unprotected Message: A message that no protection measures of any
  199. Protection Levels have been applied to.
  200. o Data Minimization: Data spareness and hiding all technically
  201. concealable information whenever possible.
  202. 2. Problem Statement
  203. The LAMPS charter contains the following Work Item:
  204. Update the specification for the cryptographic protection of email
  205. headers - both for signatures and encryption - to improve the
  206. implementation situation with respect to privacy, security,
  207. usability and interoperability in cryptographically-protected
  208. electronic mail. Most current implementations of
  209. cryptographically-protected electronic mail protect only the body
  210. of the message, which leaves significant room for attacks against
  211. otherwise-protected messages.
  212. In the following a set of challenges to be addressed:
  213. [[ TODO: enhance this section, add more items to the following ]]
  214. 2.1. Privacy
  215. o Data Minimization, which includes data spareness and hiding all
  216. technically concealable information whenever possible
  217. 2.2. Security
  218. o MITM attacks (cf. [RFC4949])
  219. 2.3. Usability
  220. o User interaction / User experience
  221. 2.4. Interoperability
  222. o Interoperability with [RFC8551] implementations
  223. 3. Use Cases
  224. In the following, the reader can find a list of the generic use cases
  225. that need to be addressed for messages with Header Protection (HP).
  226. Hoeneisen & Melnikov Expires December 28, 2020 [Page 6]
  227. Internet-Draft Header Protection S/MIME June 2020
  228. These use cases apply independently of whether S/MIME, PGP/MIME or
  229. any other technology is used to achieve HP.
  230. 3.1. Interactions
  231. 3.1.1. Main Case for Header Protection
  232. Both peers (sending and receiving side) fully support Header
  233. Protection as specified in this document; see Section 4.1.
  234. 3.1.2. Backward Compatibility
  235. The sending side fully supports Header protection as specified in
  236. this document, while the receiving side does not support any Header
  237. Protection; see Section 4.2.
  238. Note: The compatibility of legacy HP systems with this new solutions,
  239. and how to handle issues surrounding future maintenance for these
  240. legacy systems, will be decided by the LAMPS WG.
  241. 3.2. Protection Levels
  242. The following protection levels need to be considered:
  243. a) Signature and encryption
  244. Messages containing a cryptographic signature, which are also
  245. encrypted.
  246. b) Signature only
  247. Messages containing a cryptographic signature, but which are not
  248. encrypted.
  249. c) Encryption only
  250. Messages that are encrypted, but do not contain a cryptographic
  251. signature.
  252. 4. Specification
  253. This section contains the specification for Header Protection in
  254. S/MIME to update and clarifies Section 3.1 of [RFC8551] (S/MIME 4.0).
  255. This specification is likely to be integrated into S/MIME at some
  256. later stage.
  257. Furthermore, it is likely that PGP/MIME [RFC3156] will also take over
  258. this specification or parts of it.
  259. Hoeneisen & Melnikov Expires December 28, 2020 [Page 7]
  260. Internet-Draft Header Protection S/MIME June 2020
  261. This specification applies to the protection levels "signature &
  262. encryption" and "signature only" (cf. Section 3.2):
  263. Sending and receiving sides SHOULD implement "signature and
  264. encryption", which is the default to use on the sending side.
  265. Certain implementations MAY decide to send "signature only" messages,
  266. depending on the circumstances and customer requirements. Sending
  267. side MAY and receiving sides SHOULD implement "signature only".
  268. It generally is NOT RECOMMENDED to send a message with protection
  269. level "encryption only". On the other hand, messages with protection
  270. level "encryption only" might arrive at the receiving side. While
  271. not targeted to protection level "encryption only", this
  272. specification is assumed to also function for "encryption only".
  273. Receiving sides SHOULD implement "encryption only".
  274. Note: It is for further study whether or not more guidance for
  275. handling messages with protection level "encryption only" at the
  276. receiving side is needed.
  277. 4.1. Main Use Case
  278. The following covers the Interaction (cf. Section 3.1) if all
  279. parties (sending and receiving side) implement this specification.
  280. (For backward compatibility cases cf. Section 4.2).
  281. 4.1.1. MIME Format
  282. Currently there are two options in discussion:
  283. 1. The option according to the current S/MIME specification (cf.
  284. [RFC8551])
  285. 2. An alternative option that is based on the former "memory hole"
  286. approach (cf. [I-D.autocrypt-lamps-protected-headers])
  287. 4.1.1.1. S/MIME Specification
  288. As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending
  289. client MAY wrap a full MIME message in a message/RFC822 wrapper in
  290. order to apply S/MIME security services to these header fields.
  291. To help the receiving side to distinguish between forwarded and
  292. wrapped message, a Content-Type header field parameter "forwarded" is
  293. added as defined in [I-D.melnikov-iana-reg-forwarded]. Certain
  294. mailing applications might display the Inner Message as attachment
  295. otherwise.
  296. Hoeneisen & Melnikov Expires December 28, 2020 [Page 8]
  297. Internet-Draft Header Protection S/MIME June 2020
  298. The MIME structure of an Email message looks as follows:
  299. <Outer Message Header Section (unprotected)>
  300. <Outer Message Body (protected)>
  301. <MIME Header Section (wrapper)>
  302. <Inner Message Header Section>
  303. <Inner Message Body>
  304. The following example demonstrates how header section and payload of
  305. a protect body part might look like. For example, this will be the
  306. first body part of a multipart/signed message or the signed and/or
  307. encrypted payload of the application/pkcs7-mime body part. Lines
  308. prepended by "O: " are the Outer Message Header Section. Lines
  309. prepended by "I: " are the Inner Message Header Section. Lines
  310. prepended by "W: " are the wrapper (MIME Header Section):
  311. Hoeneisen & Melnikov Expires December 28, 2020 [Page 9]
  312. Internet-Draft Header Protection S/MIME June 2020
  313. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  314. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  315. O: Subject: Meeting at my place
  316. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  317. O: To: somebody@example.net
  318. O: MIME-Version: 1.0
  319. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  320. O: protocol="application/pkcs7-signature";
  321. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  322. This is a multipart message in MIME format.
  323. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  324. W: Content-Type: message/RFC822; forwarded=no
  325. W:
  326. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  327. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  328. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  329. I: MIME-Version: 1.0
  330. I: MMHS-Primary-Precedence: 3
  331. I: Subject: Meeting at my place
  332. I: To: somebody@example.net
  333. I: X-Mailer: Isode Harrier Web Server
  334. I: Content-Type: text/plain; charset=us-ascii
  335. This is an important message that I don't want to be modified.
  336. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  337. Content-Transfer-Encoding: base64
  338. Content-Type: application/pkcs7-signature
  339. [[base-64 encoded signature]]
  340. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  341. The Outer Message Header Section is unprotected, while the remainder
  342. (Outer Message Body) is protected. The Outer Message Body consists
  343. of the wrapper (MIME Header Section) and the Inner Message (Header
  344. Section and Body).
  345. The wrapper is a simple MIME Header Section with media type "message/
  346. RFC822" containing a Content-Type header field parameter
  347. "forwarded=no" followed by an empty line.
  348. The Inner Message Header Section is the same as (or a subset of) the
  349. Original Message Header Section (cf. Section 4.1.2).
  350. The Inner Message Body is the same as the Original Message Body.
  351. Hoeneisen & Melnikov Expires December 28, 2020 [Page 10]
  352. Internet-Draft Header Protection S/MIME June 2020
  353. The Original Message itself may contain any MIME structure.
  354. There may also be an additional MIME layer with media type
  355. "multipart/mixed" in the Outer Message Body to contain the Inner
  356. Message (wrapped in a "message/RFC822") along with other MIME
  357. part(s).
  358. 4.1.1.2. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
  359. Hole")
  360. An alternative Option (based on the former autocrypt "Memory Hole"
  361. approach) to be considered, is described in
  362. [I-D.autocrypt-lamps-protected-headers].
  363. Unlike the option described in Section 4.1.1.1, this option does not
  364. use a "message/RFC822" wrapper to unambigously delimit the Inner
  365. Message.
  366. The MIME structure of an Email message looks as follows:
  367. <Outer Message Header Section (unprotected)>
  368. <Outer Message Body (protected)>
  369. <Inner Message Header Section>
  370. <Inner Message Body>
  371. The following example demonstrates how header section and payload of
  372. a protect body part might look like. For example, this will be the
  373. first body part of a multipart/signed message or the signed and/or
  374. encrypted payload of the application/pkcs7-mime body part. Lines
  375. prepended by "O: " are the outer header section. Lines prepended by
  376. "I: " are the inner header section.
  377. Hoeneisen & Melnikov Expires December 28, 2020 [Page 11]
  378. Internet-Draft Header Protection S/MIME June 2020
  379. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  380. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  381. O: Subject: Meeting at my place
  382. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  383. O: MIME-Version: 1.0
  384. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  385. O: protocol="application/pkcs7-signature";
  386. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  387. This is a multipart message in MIME format.
  388. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  389. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  390. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  391. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  392. I: MIME-Version: 1.0
  393. I: MMHS-Primary-Precedence: 3
  394. I: Subject: Meeting at my place
  395. I: To: somebody@example.net
  396. I: X-Mailer: Isode Harrier Web Server
  397. I: Content-Type: text/plain; charset=us-ascii
  398. This is an important message that I don't want to be modified.
  399. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  400. Content-Transfer-Encoding: base64
  401. Content-Type: application/pkcs7-signature
  402. [[base-64 encoded signature]]
  403. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  404. The Outer Message Header Section is unprotected, while the remainder
  405. (Outer Message Body) is protected. The Outer Message Body consists
  406. of the Inner Message (Header Section and Body).
  407. The Inner Message Header Section is the same as (or a subset of) the
  408. Original Message Header Section (cf. Section 4.1.2).
  409. The Inner Message Body is the same as the Original Message Body.
  410. The Original Message itself may contain any MIME structure.
  411. There may also be an additional MIME layer with media type
  412. "multipart/mixed" in the Outer Message Body to contain the Inner
  413. Message along with other MIME part(s).
  414. Hoeneisen & Melnikov Expires December 28, 2020 [Page 12]
  415. Internet-Draft Header Protection S/MIME June 2020
  416. 4.1.2. Inner Message Header Fields
  417. It is RECOMMEND that the Inner Messages contains all the Header
  418. Fields of the Original Message with the exception of the following
  419. Header Field, which MUST NOT be included to the Inner Message nor to
  420. any other protected part of the message:
  421. o Bcc
  422. [[ TODO: Bcc handling needs to be further specified (see also
  423. Appendix A.1). Certain MUAs cannot properly decrypt messages with
  424. Bcc recipients. ]]
  425. 4.1.3. Wrapper
  426. The wrapper is a simple MIME Header Section followed by an empty line
  427. preceding the Inner Message (inside the Outer Message Body). The
  428. media type of the wrapper MUST be "message/RFC822" and SHOULD contain
  429. the Content-Type header field parameter "forwarded=no" as defined in
  430. [I-D.melnikov-iana-reg-forwarded]. The wrapper delimits unambigously
  431. the Inner Message from the rest of the message.
  432. 4.1.4. Outer Message Header Fields
  433. To maximize Privacy, it is strongly RECOMMENDED to follow the
  434. principle of Data Minimization (cf. Section 2.1).
  435. However, the Outer Message Header Section SHOULD contain the
  436. Essential Header Fields and, in addition, MUST contain the Header
  437. Fields of the MIME Header Section part to describe the encryption or
  438. signature as per [RFC8551].
  439. The following Header Fields are defined as the Essential Header
  440. Fields:
  441. o From
  442. o To (if present in the OrigM)
  443. o Cc (if present in the OrigM)
  444. o Bcc (if present in the OrigM, see also Section 4.1.2 and
  445. Appendix A.1)
  446. o Date
  447. o Message-ID
  448. Hoeneisen & Melnikov Expires December 28, 2020 [Page 13]
  449. Internet-Draft Header Protection S/MIME June 2020
  450. o Subject
  451. Some of these Header Fields are needed by the Transport (e.g. to
  452. determine the destination). Furthermore, not including certain
  453. Header Fields may trigger spam detection to flag the message as spam
  454. and/or lead to user experience (UX) issues.
  455. For further Data Minimization the value of the Subject Header Field
  456. SHOULD be obfuscated. In addition, the value of other Essential
  457. Header Fields MAY be obfuscated. Further Header Fields MAY be
  458. obfuscated, though simply not adding those to the Outer Message
  459. Header SHOULD be prefered over obfuscation. Header Field obfuscation
  460. is further specified in Section 4.1.4.1. Header Fields not
  461. obfuscated SHOULD contain the same values as in the Original Message.
  462. The MIME Header Section part is the collection of MIME Header Fields
  463. describing the following MIME structure as defined in [RFC2045]. A
  464. MIME Header Section part typically includes the following Header
  465. Fields:
  466. o MIME-Version
  467. o Content-Type
  468. o Content-Transfer-Encoding
  469. o Content-Disposition
  470. The following example shows the MIME header of an S/MIME signed
  471. message (using application/pkcs7-mime with SignedData):
  472. MIME-Version: 1.0
  473. Content-Type: application/pkcs7-mime; smime-type=signed-data;
  474. name=smime.p7m
  475. Content-Transfer-Encoding: base64
  476. Content-Disposition: attachment; filename=smime.p7m
  477. Depending on the scenario, further Header Fields MAY be exposed in
  478. the Outer Message Header Section, which is NOT RECOMMENDED unless
  479. justified. Such Header Fields may include e.g.:
  480. o References
  481. o Reply-To
  482. o In-Reply-To
  483. Hoeneisen & Melnikov Expires December 28, 2020 [Page 14]
  484. Internet-Draft Header Protection S/MIME June 2020
  485. 4.1.4.1. Obfuscation of Outer Message Header Fields
  486. If the values of the following Outer Message Header Fields are
  487. obfuscated, those SHOULD assume the following values:
  488. * Subject: ...
  489. * Message-ID: <new randomly generated Message-ID>
  490. * Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
  491. [[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the
  492. same week. ]]
  493. In certain implementations also the From, To, and/or Cc Header Field
  494. MAY be obfucated. Those may be replaced by e.g.
  495. o To: Obfuscated anonymous@anonymous.invalid [1]
  496. Such implementations need to ensure that the Transport has access to
  497. these Header Fields in clear text and is capable of processing those.
  498. A use case for obfuscation of all Outer Message Header Fields is
  499. mixnet netwerks, i.e. "onion routing" for email (e.g.[pEp.mixnet]).
  500. Note: It is for further study to what extent Header Field obfuscation
  501. (adversely) impacts spam filtering.
  502. 4.1.5. Sending Side Message Processing
  503. For a protected message the following steps are applied before a
  504. message is handed over to the Transport:
  505. 4.1.5.1. Step 1: Decide on Protection Level and Information Disclosure
  506. The entity applying protection to a message must decide:
  507. o Which protection level (signature and/or encryption) is applied to
  508. the message? This depends on user request and/or local policy as
  509. well as availability of cryptographic keys.
  510. o Which Header Fields of the Orignial Message shall be part of the
  511. Outer Message Header Section? This typically depends on local
  512. policy. By default the Essential Header Fields are part of the
  513. Outer Message Header Section; cf. Section 4.1.4.
  514. o Which of these Header Fields are to be obfuscated? This depends
  515. on local policy and/or specific Privacy requirements of the user.
  516. By default only the Subject Header Field is obfuscated; cf.
  517. Section 4.1.4.1.
  518. Hoeneisen & Melnikov Expires December 28, 2020 [Page 15]
  519. Internet-Draft Header Protection S/MIME June 2020
  520. 4.1.5.2. Step 2: Compose the Outer Message Header Section
  521. Depending on the decision in Section 4.1.5.1, compose the Outer
  522. Message Header Section. (Note that this also includes the necessary
  523. MIME Header Section part for the following protection layer.)
  524. Outer Header Fields that are not obfuscated SHOULD contain the same
  525. values as in the Original Message (except for MIME Header
  526. Section part, which depends on the protection level selected in
  527. Section 4.1.5.1).
  528. 4.1.5.3. Step 3: Apply Protection to the Original Message
  529. Depending on the protection level selected in Section 4.1.5.1 apply
  530. signature and/or encryption to the original message including the
  531. wrapper (as per [RFC8551]) and put the result to the message as Outer
  532. Message Body.
  533. The resulting (Outer) Message is then typically handed over to the
  534. Transport.
  535. [[ TODO: Example ]]
  536. 4.1.6. Receiving Side Message Processing
  537. When a protected message is received the following steps are applied:
  538. 4.1.6.1. Step 1: Decrypt message and/or check signature
  539. Depending on the protection level the received message is decrypted
  540. and/or its signature is checked as per [RFC8551].
  541. 4.1.6.2. Step 2: Construct the Receiving User Facing Message
  542. The Receiving User Facing Message is constructed as follows:
  543. o The Header Section of the Receiving User Facing Message MUST
  544. consist of the Outer Message Header Fields that are not contained
  545. in the Inner Message Header Section, and the Inner Message Header
  546. Fields (i.e. the Inner Message Header Field MUST always take
  547. precedence).
  548. o The Body of the Receiving User Facing Message Body MUST be the
  549. same as the Inner Message Body.
  550. The resulting message is handed over for further processing, which
  551. typically involves rendering it to the user.
  552. Hoeneisen & Melnikov Expires December 28, 2020 [Page 16]
  553. Internet-Draft Header Protection S/MIME June 2020
  554. [[ TODO: Do we need to take special care for HFs, which may appear
  555. multiple times, e.g. Received HF? ]]
  556. Note: It is for further study whether and, if yes, how the Outer
  557. Message Header Section (as received from the Transport) is preserved
  558. for the user.
  559. 4.1.7. Header Field Flow
  560. The Following figure depicts the different message representations
  561. (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
  562. from:
  563. OrigM InnerM Outer(S) OuterM(R) RUFM
  564. <Trans-HF> > <Trans-HF>
  565. From (OrigM) = From
  566. To (OrigM) = To
  567. Cc (OrigM) = Cc
  568. Bcc (OrigM) = Bcc* > Bcc
  569. Date (OrigM) = Date
  570. Message-ID (OrigM)= Message-ID
  571. Subject (new) = Subject
  572. <MIME-HSp> (new) = <MIME-HSp>
  573. PROTECTED: PROTECTED:
  574. <Wrapper> (new) = <Wrapper>
  575. From > From > From = From > From
  576. To > To > To = To > To
  577. Cc* > Cc > Cc = Cc > Cc
  578. Bcc*
  579. Date > Date > Date = Date > Date
  580. Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
  581. Subject > Subject > Subject = Subject > Subject
  582. <More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
  583. <MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
  584. <Body> > <Body> > <Body> = <Body> > <Body>
  585. <Signature>* (new)= <Signature>
  586. Legend:
  587. o OuterM(S): Outer Message (OuterM) at sending side (before
  588. processing by Transport)
  589. o OuterM(R): Outer Message at receiving side (as received by
  590. Transport)
  591. Hoeneisen & Melnikov Expires December 28, 2020 [Page 17]
  592. Internet-Draft Header Protection S/MIME June 2020
  593. o InnerM: Inner Message (that protection is applied to)
  594. o RUFM: Receiving User Facing Message
  595. o More-HF: Additional Header Fields (HF) in the Original Message
  596. (OrigM)
  597. o Wrapper: MIME Header Section; with media type (message/RFC822) to
  598. unambigously delimit the inner message from the rest of the
  599. message.
  600. o MIME-HSp: MIME Header Section part to describe the encryption or
  601. signature as per [RFC8551]
  602. o Trans-HF: Header Fields added in Transit (between sending and
  603. receiving side)
  604. o >: taken over / copied from last column
  605. o =: propagates unchanged, unless something unusual (e.g. attack)
  606. happens
  607. o *: HF that is often not present (also further HF may not be
  608. present). If a HF is not present, naturally it can neither be
  609. taken over nor propagated.
  610. o (new) / (OrigM): HF or MIME-HSp is generated depending on the
  611. decision in Section 4.1.5.1, while '(new)' / '(OrigM)' designate
  612. the default.
  613. 4.2. Backward Compatibility Use Case
  614. [I-D.autocrypt-lamps-protected-headers] describes a possibility to
  615. achieve backward compatibility with existing S/MIME (and PGP/MIME)
  616. implementations unaware of this specification (Legacy Display). It
  617. mainly focuses on email clients that do not render emails using
  618. header protection (nicely) and may confuse the user. While this has
  619. been observed occasionally in PGP/MIME (cf. [RFC3156]), the extent
  620. of this problem with S/MIME implementations is still unclear. (Note:
  621. At this time, none of the samples in
  622. [I-D.autocrypt-lamps-protected-headers] applies header protection as
  623. specified in Section 3.1 of [RFC8551], which is wrapping as Media
  624. Type "message/RFC822".)
  625. Should serious backward compatibility issues with rendering at the
  626. receiver reveal, the Legacy Display format described in
  627. [I-D.autocrypt-lamps-protected-headers] may serve as a basis to
  628. mitigate those (backward compatibility use case).
  629. Hoeneisen & Melnikov Expires December 28, 2020 [Page 18]
  630. Internet-Draft Header Protection S/MIME June 2020
  631. Another variant of backward compatibility has been implemented by pEp
  632. [I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has
  633. implemented this for PGP/MIME (but not yet S/MIME).
  634. 5. Security Considerations
  635. [[ TODO ]]
  636. 6. Privacy Considerations
  637. [[ TODO ]]
  638. 7. IANA Considerations
  639. This document requests no action from IANA.
  640. [[ RFC Editor: This section may be removed before publication. ]]
  641. 8. Acknowledgments
  642. The authors would like to thank the following people who have
  643. provided helpful comments and suggestions for this document: Claudio
  644. Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol,
  645. Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei
  646. Chuang.
  647. 9. References
  648. 9.1. Normative References
  649. [I-D.ietf-lamps-header-protection-requirements]
  650. Melnikov, A. and B. Hoeneisen, "Problem Statement and
  651. Requirements for Header Protection", draft-ietf-lamps-
  652. header-protection-requirements-01 (work in progress),
  653. October 2019.
  654. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
  655. Extensions (MIME) Part One: Format of Internet Message
  656. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
  657. <https://www.rfc-editor.org/info/rfc2045>.
  658. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  659. Requirement Levels", BCP 14, RFC 2119,
  660. DOI 10.17487/RFC2119, March 1997,
  661. <https://www.rfc-editor.org/info/rfc2119>.
  662. Hoeneisen & Melnikov Expires December 28, 2020 [Page 19]
  663. Internet-Draft Header Protection S/MIME June 2020
  664. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
  665. DOI 10.17487/RFC5322, October 2008,
  666. <https://www.rfc-editor.org/info/rfc5322>.
  667. [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
  668. Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
  669. Message Specification", RFC 8551, DOI 10.17487/RFC8551,
  670. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
  671. 9.2. Informative References
  672. [I-D.autocrypt-lamps-protected-headers]
  673. Einarsson, B., juga, j., and D. Gillmor, "Protected
  674. Headers for Cryptographic E-mail", draft-autocrypt-lamps-
  675. protected-headers-02 (work in progress), December 2019.
  676. [I-D.melnikov-iana-reg-forwarded]
  677. Melnikov, A. and B. Hoeneisen, "IANA Registration of
  678. Content-Type Header Field Parameter 'forwarded'", draft-
  679. melnikov-iana-reg-forwarded-00 (work in progress),
  680. November 2019.
  681. [I-D.pep-email]
  682. Marques, H., "pretty Easy privacy (pEp): Email Formats and
  683. Protocols", draft-marques-pep-email-02 (work in progress),
  684. October 2018.
  685. [pEp.mixnet]
  686. pEp Foundation, "Mixnet", June 2020,
  687. <https://dev.pep.foundation/Mixnet>.
  688. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
  689. "MIME Security with OpenPGP", RFC 3156,
  690. DOI 10.17487/RFC3156, August 2001,
  691. <https://www.rfc-editor.org/info/rfc3156>.
  692. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
  693. FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
  694. <https://www.rfc-editor.org/info/rfc4949>.
  695. [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
  696. "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
  697. RFC 6376, DOI 10.17487/RFC6376, September 2011,
  698. <https://www.rfc-editor.org/info/rfc6376>.
  699. Hoeneisen & Melnikov Expires December 28, 2020 [Page 20]
  700. Internet-Draft Header Protection S/MIME June 2020
  701. [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
  702. Authorizing Use of Domains in Email, Version 1", RFC 7208,
  703. DOI 10.17487/RFC7208, April 2014,
  704. <https://www.rfc-editor.org/info/rfc7208>.
  705. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
  706. Message Authentication, Reporting, and Conformance
  707. (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
  708. <https://www.rfc-editor.org/info/rfc7489>.
  709. 9.3. URIs
  710. [1] mailto:anonymous@anonymous.invalid
  711. Appendix A. Additional information
  712. A.1. Stored Variants of Messages with Bcc
  713. Messages containing at least one recipient address in the Bcc header
  714. field may appear in up to three different variants:
  715. 1. The message for the recipient addresses listed in To or Cc header
  716. fields, which must not include the Bcc header field neither for
  717. signature calculation nor for encryption.
  718. 2. The message(s) sent to the recipient addresses in the Bcc header
  719. field, which depends on the implementation:
  720. a) One message for each recipient in the Bcc header field
  721. separately with a Bcc header field containing only the address of
  722. the recipient it is sent to
  723. b) The same message for each recipient in the Bcc header field
  724. with a Bcc header field containing an indication such as
  725. "Undisclosed recipients" (but no addressees)
  726. c) The same message for each recipient in the Bcc header field
  727. which does not include a Bcc header field (this message is
  728. identical to 1. / cf. above)
  729. 3. The message stored in the 'Sent'-Folder of the sender, which
  730. usually contains the Bcc unchanged from the original message,
  731. i.e. with all recipient addresses.
  732. Hoeneisen & Melnikov Expires December 28, 2020 [Page 21]
  733. Internet-Draft Header Protection S/MIME June 2020
  734. Appendix B. Document Changelog
  735. [[ RFC Editor: This section is to be removed before publication ]]
  736. o draft-ietf-lamps-header-protection-00
  737. * Initial version (text partialy taken over from
  738. [I-D.ietf-lamps-header-protection-requirements]
  739. Appendix C. Open Issues
  740. [[ RFC Editor: This section should be empty and is to be removed
  741. before publication. ]]
  742. o Decide on format of obfuscated HFs, in particular Date HF
  743. (Section 4.1.4.1)
  744. o Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1)
  745. o More examples (e.g. in Section 4.1.5)
  746. o Should Outer Message Header Section (as received) be preserved for
  747. the user? (Section 4.1.6.2)
  748. o Do we need to take special care of HFs that may appear multiple
  749. times, e.g. Received HF? (Section 4.1.6.2)
  750. o Change adding Content-Type header field parameter "forwarded" from
  751. SHOULD to MUST (Section 4.1.3)?
  752. o Decide on whether or not merge requirements from
  753. [I-D.ietf-lamps-header-protection-requirements] into this
  754. document.
  755. o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
  756. merge into this document.
  757. o Enhance Introduction and Problem Statement sections
  758. o Decide on whether or not specification for more legacy HP
  759. requirements should be added to this document
  760. o Improve definitions in Section 3.2
  761. o Privacy Considerations Section 6
  762. o Security Considerations Section 5
  763. Hoeneisen & Melnikov Expires December 28, 2020 [Page 22]
  764. Internet-Draft Header Protection S/MIME June 2020
  765. Authors' Addresses
  766. Bernie Hoeneisen
  767. pEp Foundation
  768. Oberer Graben 4
  769. CH-8400 Winterthur
  770. Switzerland
  771. Email: bernie.hoeneisen@pep.foundation
  772. URI: https://pep.foundation/
  773. Alexey Melnikov
  774. Isode Ltd
  775. 14 Castle Mews
  776. Hampton, Middlesex TW12 2NP
  777. UK
  778. Email: alexey.melnikov@isode.com
  779. Hoeneisen & Melnikov Expires December 28, 2020 [Page 23]