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.

1522 lines
56 KiB

  1. Network Working Group B. Hoeneisen
  2. Internet-Draft pEp Foundation
  3. Intended status: Informational A. Melnikov
  4. Expires: January 10, 2021 Isode Ltd
  5. July 09, 2020
  6. [krb: the terms mail user agent, Mail User Agent, user agent, and MUA are all used interchangeably throughout the draft. I'd suggest using Mail User Agent (MUA) at the beginning of the doc and then using MUA for the rest, unless there's a grammatical need to use the full term, which I'll do my best to note. This will maintain consistency and reduce confusion.]
  7. Header Protection for S/MIME
  8. draft-ietf-lamps-header-protection-00
  9. Abstract
  10. Privacy and security issues with email header protection in S/MIME
  11. have been identified for some time. However, the desire to fix these
  12. issues has only recently been expressed in the IETF LAMPS Working
  13. Group. The existing S/MIME specification is to be updated regarding
  14. header protection.
  15. This document describes the problem statement, generic use cases, and
  16. the S/MIME specification for header protection.
  17. Status of This Memo
  18. This Internet-Draft is submitted in full conformance with the
  19. provisions of BCP 78 and BCP 79.
  20. Internet-Drafts are working documents of the Internet Engineering
  21. Task Force (IETF). Note that other groups may also distribute
  22. working documents as Internet-Drafts. The list of current Internet-
  23. Drafts is at https://datatracker.ietf.org/drafts/current/.
  24. Internet-Drafts are draft documents valid for a maximum of six months
  25. and may be updated, replaced, or obsoleted by other documents at any
  26. time. It is inappropriate to use Internet-Drafts as reference
  27. material or to cite them other than as "work in progress."
  28. This Internet-Draft will expire on January 10, 2021.
  29. Copyright Notice
  30. Copyright (c) 2020 IETF Trust and the persons identified as the
  31. document authors. All rights reserved.
  32. This document is subject to BCP 78 and the IETF Trust's Legal
  33. Provisions Relating to IETF Documents
  34. (https://trustee.ietf.org/license-info) in effect on the date of
  35. publication of this document. Please review these documents
  36. carefully, as they describe your rights and restrictions with respect
  37. Hoeneisen & Melnikov Expires January 10, 2021 [Page 1]
  38. Internet-Draft Header Protection S/MIME July 2020
  39. to this document. Code Components extracted from this document must
  40. include Simplified BSD License text as described in Section 4.e of
  41. the Trust Legal Provisions and are provided without warranty as
  42. described in the Simplified BSD License.
  43. Table of Contents
  44. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
  45. 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
  46. 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  47. 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
  48. 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6
  49. 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
  50. 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6
  51. 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 7
  52. 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  53. 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 7
  54. 3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 7
  55. 3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 7
  56. 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 9
  57. 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9
  58. 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 10
  59. 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 10
  60. 4.1.2. Inner Message Header Fields . . . . . . . . . . . . . 15
  61. 4.1.3. Wrapper . . . . . . . . . . . . . . . . . . . . . . . 16
  62. 4.1.4. Outer Message Header Fields . . . . . . . . . . . . . 16
  63. 4.1.5. Receiving User Facing Message Header Fields . . . . . 18
  64. 4.1.6. Header Field Flow . . . . . . . . . . . . . . . . . . 18
  65. 4.1.7. Sending Side Message Processing . . . . . . . . . . . 20
  66. 4.1.8. Receiving Side Message Processing . . . . . . . . . . 21
  67. 4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 21
  68. 4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 21
  69. 4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 22
  70. 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
  71. 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
  72. 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
  73. 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
  74. 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
  75. 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
  76. 9.2. Informative References . . . . . . . . . . . . . . . . . 24
  77. 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
  78. Appendix A. Additional information . . . . . . . . . . . . . . . 25
  79. A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 25
  80. Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 26
  81. Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 26
  82. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
  83. Hoeneisen & Melnikov Expires January 10, 2021 [Page 2]
  84. Internet-Draft Header Protection S/MIME July 2020
  85. 1. Introduction
  86. A range of protocols for the protection of electronic mail (email)
  87. exists, which allows to assess the authenticity and integrity of the
  88. email headers section or selected header fields (HF) from the domain-
  89. level perspective, specifically DomainKeys Identified Mail (DKIM)
  90. [RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
  91. based Message Authentication, Reporting, and Conformance (DMARC)
  92. [RFC7489]. These protocols, while essential to responding to a range
  93. of attacks on email, do not offer (full) end-to-end protection to the
  94. header section and are not capable of providing privacy for the
  95. information contained therein.
  96. The need for means of Data Minimization, which includes data
  97. sparseness and hiding all technically concealable information
  98. whenever possible, has grown in importance over the past several
  99. years.
  100. A standard for end-to-end protection of the email header section
  101. exists for S/MIME version 3.1 and later. (cf. [RFC8551]):
  102. In order to protect outer, non-content-related message header
  103. fields (for instance, the "Subject", "To", "From", and "Cc"
  104. fields), the sending client MAY wrap a full MIME message in a
  105. message/RFC822 wrapper in order to apply S/MIME security services
  106. to these header fields.
  107. No mechanism for header protection (HP) has been standardized for
  108. PGP/MIME (Pretty Good Privacy) [RFC3156] yet.
  109. Several varying implementations of end-to-end protections for email
  110. header sections exist, though the total number of such
  111. implementations appears to be rather low.
  112. Some LAMPS WG participants expressed the opinion that regardless of
  113. the mechanism chosen, it should not be limited to S/MIME, but also
  114. applicable to PGP/MIME.
  115. This document describes the problem statement (Section 2), generic
  116. use cases (Section 3) and the specification for Header Protection
  117. (Section 4).
  118. [I-D.ietf-lamps-header-protection-requirements] defines the
  119. requirements that this specification is based on.
  120. This document is in early draft state and contains a proposal on
  121. which to base future discussions of this topic. In any case, the
  122. final mechanism is to be determined by the IETF LAMPS WG.
  123. Hoeneisen & Melnikov Expires January 10, 2021 [Page 3]
  124. Internet-Draft Header Protection S/MIME July 2020
  125. 1.1. Requirements Language
  126. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  127. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  128. document are to be interpreted as described in [RFC2119].
  129. 1.2. Terms
  130. The following terms are defined for the scope of this document:
  131. o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
  132. form of active wiretapping attack in which the attacker intercepts
  133. and selectively modifies communicated data to masquerade as one or
  134. more of the entities involved in a communication association."
  135. o S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.
  136. [RFC8551])
  137. o PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156])
  138. o Message: An Email Message consisting of Header Fields
  139. (collectively called "the Header Section of the message")
  140. followed, optionally, by a Body; cf. [RFC5322].
  141. Note: To avoid ambiguity, this document does not use the terms
  142. "Header" or "Headers" in isolation, but instead always uses
  143. "Header Field" to refer to the individual field and "Header
  144. Section" to refer to the entire collection; cf. [RFC5322].
  145. o Header Field (HF): cf. [RFC5322] Header Fields are lines beginning
  146. with a field name, followed by a colon (":"), followed by a field
  147. body (value), and terminated by CRLF; cf. [RFC5322].
  148. o Header Section (HS): The Header Section is a sequence of lines of
  149. characters with special syntax as defined in [RFC5322]. It is the
  150. (top) section of a Message containing the Header Fields.
  151. o Body: The Body is simply a sequence of characters that follows the
  152. Header Section and is separated from the Header Section by an
  153. empty line (i.e., a line with nothing preceding the CRLF); cf
  154. [RFC5322]. It is the (bottom) section of Message containing the
  155. payload of a Message. Typically, the Body consists of a
  156. (multipart) MIME [RFC2045] construct.
  157. o MIME Header Fields: Header Fields describing content of a MIME
  158. entity [RFC2045], in particular the MIME structure. Each MIME
  159. Header Field name starts with "Content-" prefix.
  160. Hoeneisen & Melnikov Expires January 10, 2021 [Page 4]
  161. Internet-Draft Header Protection S/MIME July 2020
  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 Essential Header Fields (EHF): The minimum set of Header Fields an
  168. Outer Message Header Section SHOULD contain; cf. Section 4.1.4.
  169. o Header Protection (HP): cryptographic protection of email Header
  170. Sections (or parts of it) for signatures and/or encryption
  171. o Protection Levels (PL): One of 'signature and encryption',
  172. 'signature only' or 'encryption only' (cf. Section 3.2)
  173. o Protected: Protected refers to the parts of a Message where
  174. protection measures of any Protection Level have been applied to.
  175. o Protected Message: A Message that protection measures of any
  176. Protection Levels have been applied to.
  177. o Unprotected: Unprotected refers to the parts of a Message where no
  178. protection measures of any Protection Levels have been applied to.
  179. o Unprotected Message: A Message that no protection measures of any
  180. Protection Levels have been applied to.
  181. o Original Message (OrigM): The message to be protected before any
  182. protection related processing has been applied on the sending
  183. side.
  184. o Inner Message (InnerM): The message to be protected, i.e. which
  185. wrapping and protection measures are applied to on the sending
  186. side or the result of decryption and unwrapping on the receiving
  187. side respectively. Typically, the Inner Message is in clear text.
  188. The Inner Message is a subset of (or the same as) the Original
  189. Message (cf. Section 4.1.2). The Inner Message must be the same
  190. on the sending and the receiving side.
  191. o Outer Message (OuterM): The Message as handed over to the
  192. Submission Entity or received from the last hop respectively. The
  193. Outer Message normally differs on the sending and the receiving
  194. side (e.g. new Header Fields are added by intermediary nodes).
  195. o Receiving User Facing Message (RUFM): The message used for
  196. rendering at the receiving side. Typically this is the same as
  197. the Inner Message.
  198. Hoeneisen & Melnikov Expires January 10, 2021 [Page 5]
  199. Internet-Draft Header Protection S/MIME July 2020
  200. o Submission Entity: The entity taking care of further processing of
  201. the Message (incl. transport towards the receiver), after
  202. protection measures have been applied to. It typically determines
  203. the destination recipients by reading the To, Cc and Bcc Header
  204. Fields (of the Outer Message).
  205. Note: The Submission Entity varies among implementations, mainly
  206. depending on the stage, where protection measures are applied to:
  207. It could be e.g. a Message Submission Agent (MSA) [RFC6409] or
  208. another (proprietary) solution. The latter is particularly
  209. relevant, if protection is implemented as a plugin solution or for
  210. mixnet networks, i.e. "onion routing" for email (e.g.
  211. [pEp.mixnet]).
  212. o Data Minimization: Data sparseness and hiding of all technically
  213. concealable information whenever possible.
  214. 2. Problem Statement
  215. The LAMPS charter contains the following Work Item:
  216. Update the specification for the cryptographic protection of email
  217. headers - both for signatures and encryption - to improve the
  218. implementation situation with respect to privacy, security,
  219. usability and interoperability in cryptographically-protected
  220. electronic mail. Most current implementations of
  221. cryptographically-protected electronic mail protect only the body
  222. of the message, which leaves significant room for attacks against
  223. otherwise-protected messages.
  224. In the following a set of challenges to be addressed:
  225. [[ TODO: enhance this section, add more items to the following ]]
  226. 2.1. Privacy
  227. o Data Minimization, which includes data sparseness and hiding all
  228. technically concealable information whenever possible
  229. 2.2. Security
  230. o MITM attacks (cf. [RFC4949])
  231. 2.3. Usability
  232. o User interaction / User experience
  233. Hoeneisen & Melnikov Expires January 10, 2021 [Page 6]
  234. Internet-Draft Header Protection S/MIME July 2020
  235. 2.4. Interoperability
  236. o Interoperability with [RFC8551] implementations
  237. 3. Use Cases
  238. In the following, the reader can find a list of the generic use cases
  239. that need to be addressed for Messages with Header Protection (HP).
  240. These use cases apply regardless of technology (S/MIME, PGP/MIME,
  241. etc.) used to achieve HP.
  242. 3.1. Interactions
  243. The following use cases assume that at least the sending side
  244. supports Header Protection as specified in this document. Receiving
  245. sides that support this specification are expected to be able to
  246. distinguish between Messages that Header Protection - as specified in
  247. this document - has been applied to and (legacy) Mail user Agents [KRB: capitalize "user"]
  248. (MUAs) not implementing this specification.
  249. [[TODO: Verify once solution is stable and update last sentence ]]
  250. 3.1.1. Main Use Case
  251. Both peers (sending and receiving side) (fully) [krb: why is "fully" in parentheses? I'd reword as follows: "Both the sending and receiving peers fully support..."] support Header
  252. Protection as specified in this document.
  253. The main use case is specified in Section 4.1.
  254. 3.1.2. Backward Compatibility Use Cases
  255. Regarding backwards compatibility [krb: add comma after compatibility] the main distinction is based on
  256. whether or not the receiving side conforms to MIME according to
  257. [RFC2046], ff., which in particular [krb: delete "particular"] also includes Section 2 of
  258. [RFC2049] on "MIME Conformance". In the following an excerpt of
  259. paragraphs relevant in this context:
  260. Hoeneisen & Melnikov Expires January 10, 2021 [Page 7]
  261. Internet-Draft Header Protection S/MIME July 2020
  262. A mail user agent that is MIME-conformant MUST:
  263. [krb: suggest total reword. Easier to type it out rather than individual marks. This is intended to replace the two paragraphs above. "According to [RFC2046], the main concern with regard to backwards compatibility is based upon whether or not the receiving side conforms to MIME. This document also references Section 2 of [RFC2049] on "Mime Conformance", which states that a Mail User Agent (MUA) that is MIME-conformant MUST handle messages as follows:"]
  264. [...]
  265. -- Recognize and display at least the RFC822 message
  266. encapsulation (message/rfc822) in such a way as to
  267. preserve any recursive structure, that is, displaying
  268. or offering to display the encapsulated data in
  269. accordance with its media type.
  270. -- Treat any unrecognized subtypes as if they were
  271. "application/octet-stream".
  272. [...]
  273. [krb: maybe a display issue on my end, but this is indented further than other non-quote paragraphs] A user agent that meets the above conditions is said to be MIME-
  274. conformant. The meaning of this phrase is that it is assumed to be
  275. "safe" to send virtually any kind of properly-marked data to users
  276. of such mail systems, because such systems will at least be able to
  277. treat the data as undifferentiated binary, and will not simply
  278. splash it onto the screen of unsuspecting users. [krb: again, suggesting total reword. "A Mail User Agent that meets the above criteria is considered MIME-conformant, and is assumed to be "safe" to send properly-marked data to users of this MUA. MIME-conformant MUAs are able to treat data as undifferentiated binary, and will not default to displaying it to unsuspecting users." or something like this. :) ]
  279. Note: The compatibility of legacy HP systems with this new solution,
  280. and how to handle issues surrounding future maintenance for these
  281. legacy systems, will be decided by the LAMPS WG.
  282. 3.1.2.1. Receiving Side MIME-Conformant
  283. The sending side (fully) [krb: again, why is this in parentheses] supports Header Protection as specified in
  284. this document, while the receiving side does not support this
  285. specification. The receiving side is MIME-conformant according to
  286. [RFC2045], ff. (cf. Section 3.1.2),
  287. This use case is specified in Section 4.2.1.
  288. Note: This case is expected to just work fine [krb: suggest "This case should perform as expected if the sending side applies this specification as outlined in Section 4.1."], if the sending side
  289. applies specification for the main use case Section 4.1.
  290. [[TODO: Verify once solution is stable and update last sentence ]]
  291. 3.1.2.2. Receiving Side Not MIME-Conformant
  292. The sending side (fully) [krb: again, why is this in parentheses] supports Header Protection as specified in
  293. this document, while the receiving side does not support this
  294. specification. The receiving side is *not* MIME-conformant according
  295. to [RFC2045], ff. (cf. Section 3.1.2) either [krb: delete "either"].
  296. Hoeneisen & Melnikov Expires January 10, 2021 [Page 8]
  297. Internet-Draft Header Protection S/MIME July 2020
  298. This use case is specified in Section 4.2.2. [krb: this should be with the rest of the above paragraph.]
  299. 3.2. Protection Levels
  300. The following protection levels need to be considered:
  301. a) Signature and encryption
  302. Messages containing a cryptographic signature, which are also
  303. encrypted. [krb: "...signature and are encrypted."]
  304. b) Signature only
  305. Messages containing a cryptographic signature, but which are not
  306. encrypted. [krb: "...signature but are not encrypted."]
  307. c) Encryption only
  308. Messages that are encrypted, but do not contain a cryptographic
  309. signature.
  310. 4. Specification
  311. This section contains the specification for Header Protection in
  312. S/MIME to update and it clarifies Section 3.1 of [RFC8551] (S/MIME
  313. 4.0). [krb: This is a little unclear. Do you mean that this spec both updates and clarifies the linked section of 8551? If so, change "...to update and clarify Section..."]
  314. Furthermore, it is likely that PGP/MIME [RFC3156] will also
  315. incorporate this specification or parts of it.
  316. This specification applies to the protection levels "signature &
  317. encryption" and "signature only" (cf. Section 3.2):
  318. Sending and receiving sides MUST implement "signature and
  319. encryption" [krb: "...implement the "signature and encryption" protection level, which is the default level for the sending side."], which is the default to use on the sending side. [krb: question -- does this mean the "signature and encryption" level must be implemented in a way that it's the default? If that's the case, you may want to make this clearer, because as written, it almost sounds optional.]
  320. Certain implementations MAY decide to send "signature only" messages,
  321. depending on the circumstances and customer requirements. Sending
  322. side MAY and receiving sides MUST implement "signature only". [krb: "signature only" what, messages? Protection level? Please clarify.]
  323. It generally is NOT RECOMMENDED to send a message with protection
  324. level "encryption only". On the other hand, messages with protection
  325. level "encryption only" might arrive at the receiving side. [krb: Why or how would this happen? Consider including an example.] While
  326. not targeted to protection level "encryption only", this
  327. specification is assumed to also function for "encryption only".
  328. Receiving sides SHOULD implement "encryption only". [krb: Is this implementation at a minimum? If so, please clarify.]
  329. Hoeneisen & Melnikov Expires January 10, 2021 [Page 9]
  330. Internet-Draft Header Protection S/MIME July 2020
  331. Note: It is for further study whether or not more guidance for
  332. handling messages with protection level "encryption only" at the
  333. receiving side is needed. [krb: "Further study is necessary to determine whether additional guidance for handling messages with "encryption only" protection is needed."]
  334. 4.1. Main Use Case
  335. This section applies to the main use case, where both peers (sending
  336. and receiving side) (fully) [krb: again, why is this in parentheses, and I suggest rewording: "both the sending and receiving peers fully support..."] support Header Protection as specified
  337. herein (cf. Section 3.1.1).
  338. Note: The sending side specification of the main use case is also
  339. applicable to the cases, where [krb: "...to cases where the..."] the sending side (fully) [krb: again, why is this in parentheses] supports
  340. Header Protection as specified herein, while the receiving side does
  341. not support this specification, but [krb: "...side does not, but is MIME-conformant..."] is MIME-conformant according to
  342. [RFC2045], ff. (cf. Section 3.1.2) and Section 3.1.2.1)
  343. Further backward compatibility cases are defined in Section 4.2. [krb: I'd add this to the first paragraph of this section.]
  344. 4.1.1. MIME Format
  345. Currently there are two options in discussion:
  346. 1. The option according to the current S/MIME specification (cf.
  347. [RFC8551])
  348. 2. An alternative option that is based on the former "memory hole"
  349. approach (cf. [I-D.autocrypt-lamps-protected-headers])
  350. 4.1.1.1. S/MIME Specification
  351. As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending
  352. client MAY wrap a full MIME message in a message/RFC822 wrapper in
  353. order to apply S/MIME security services to these header fields.
  354. To help the receiving side to distinguish between forwarded and
  355. wrapped message [krb: "messages"], a [krb: "a" -> "the"] Content-Type header field parameter "forwarded" is
  356. added as defined in [I-D.melnikov-iana-reg-forwarded]. Certain
  357. mailing applications might display the Inner Message as [krb: add "an"] attachment
  358. otherwise.
  359. The MIME structure of an Email message looks as follows:
  360. Hoeneisen & Melnikov Expires January 10, 2021 [Page 10]
  361. Internet-Draft Header Protection S/MIME July 2020
  362. <Outer Message Header Section (unprotected)>
  363. <Outer Message Body (protected)>
  364. <MIME Header Section (wrapper)>
  365. <Inner Message Header Section>
  366. <Inner Message Body>
  367. The following example demonstrates how [krb: add "the"] header section and payload of
  368. a protected body part might look like [krb: "look like" -> "appear"]. For example, this will be the
  369. first body part [krb: "The following example illustrates the first body portion of a..."] of a multipart/signed message or the signed and/or
  370. encrypted payload of the application/pkcs7-mime body part. Lines
  371. prepended by "O: " are the Outer Message Header Section. Lines
  372. prepended by "I: " are the Inner Message Header Section. Lines
  373. prepended by "W: " are the wrapper (MIME Header Section):
  374. [krb: this is structured oddly. Suggest a new paragraph.
  375. "Lines are prepended as follows:
  376. O: Outer Message Header Section
  377. I: Inner Message Header Section
  378. W: Wrapper Section]
  379. Hoeneisen & Melnikov Expires January 10, 2021 [Page 11]
  380. Internet-Draft Header Protection S/MIME July 2020
  381. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  382. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
  383. O: Subject: Meeting at my place
  384. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  385. O: To: somebody@example.net
  386. O: MIME-Version: 1.0
  387. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  388. O: protocol="application/pkcs7-signature";
  389. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  390. This is a multipart message in MIME format.
  391. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  392. W: Content-Type: message/RFC822; forwarded=no
  393. W:
  394. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  395. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  396. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
  397. I: MIME-Version: 1.0
  398. I: MMHS-Primary-Precedence: 3
  399. I: Subject: Meeting at my place
  400. I: To: somebody@example.net
  401. I: X-Mailer: Isode Harrier Web Server
  402. I: Content-Type: text/plain; charset=us-ascii
  403. This is an important message that I don't want to be modified.
  404. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  405. Content-Transfer-Encoding: base64
  406. Content-Type: application/pkcs7-signature
  407. [[base-64 encoded signature]]
  408. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  409. The Outer Message Header Section is unprotected, while the remainder
  410. (Outer Message Body) is protected. The Outer Message Body consists
  411. of the wrapper (MIME Header Section) and the Inner Message (Header
  412. Section and Body).
  413. The wrapper is a simple MIME Header Section with media type "message/
  414. RFC822" containing a Content-Type header field parameter
  415. "forwarded=no" followed by an empty line.
  416. The Inner Message Header Section is the same as (or a subset of) the
  417. Original Message Header Section (cf. Section 4.1.2).
  418. The Inner Message Body is the same as the Original Message Body.
  419. Hoeneisen & Melnikov Expires January 10, 2021 [Page 12]
  420. Internet-Draft Header Protection S/MIME July 2020
  421. The Original Message itself may contain any MIME structure.
  422. 4.1.1.2. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
  423. Hole")
  424. An alternative option (based on the former autocrypt "Memory Hole"
  425. approach) to be considered, is described in
  426. [I-D.autocrypt-lamps-protected-headers].
  427. Unlike the option described in Section 4.1.1.1, this option does not
  428. use a "message/RFC822" wrapper to unambiguously delimit the Inner
  429. Message.
  430. Before choosing this option, [krb: add "the following"] two issues must be assessed to ensure, [krb: remove comma]
  431. no interoperability issues result from it:
  432. 1. How current MIME parser implementations treat non-MIME Header
  433. Fields, which are not part of the outermost MIME entity and not
  434. part of a message wrapped into a MIME entity of media type
  435. "message/rfc822", and how such messages are rendered to the user.
  436. [I-D.autocrypt-lamps-protected-headers] provides some examples
  437. for testing this.
  438. 2. MIME-conformance, i.e. whether or not this option is (fully) [krb: again, parentheses]
  439. MIME-conformant [RFC2045] ff., in particular also Section 5.1. of
  440. [RFC2046] on "Multipart Media Type). In the following an excerpt
  441. of paragraphs that may be relevant in this context: [krb: suggest total reword. Easier to type it out rather than individual marks. "Whether or not this option is fully MIME-conformant per [RFC2045] ff., and Section 5.1 of [RFC2046] on "Multipart Media Type". The following excerpt from Section 5.1 are of particular relevance here:" Also, not sure if the quotes themselves are formatted properly--double check.]
  442. The only header fields that have defined meaning for body parts
  443. are those the names of which begin with "Content-". All other
  444. header fields may be ignored in body parts. Although they
  445. should generally be retained if at all possible, they may be
  446. discarded by gateways if necessary. Such other fields are
  447. permitted to appear in body parts but must not be depended on.
  448. "X-" fields may be created for experimental or private
  449. purposes, with the recognition that the information they
  450. contain may be lost at some gateways.
  451. Hoeneisen & Melnikov Expires January 10, 2021 [Page 13]
  452. Internet-Draft Header Protection S/MIME July 2020
  453. NOTE: The distinction between an RFC 822 message and a body
  454. part is subtle, but important. A gateway between Internet and
  455. X.400 mail, for example, must be able to tell the difference
  456. between a body part that contains an image and a body part
  457. that contains an encapsulated message, the body of which is a
  458. JPEG image. In order to represent the latter, the body part
  459. must have "Content-Type: message/rfc822", and its body (after
  460. the blank line) must be the encapsulated message, with its own
  461. "Content-Type: image/jpeg" header field. The use of similar
  462. syntax facilitates the conversion of messages to body parts,
  463. and vice versa, but the distinction between the two must be
  464. understood by implementors. (For the special case in which
  465. parts actually are messages, a "digest" subtype is also
  466. defined.)
  467. The MIME structure of an Email message looks as follows:
  468. <Outer Message Header Section (unprotected)>
  469. <Outer Message Body (protected)>
  470. <Inner Message Header Section>
  471. <Inner Message Body>
  472. The following example demonstrates how the header section and payload
  473. of a protected body part might appear. For example, this will [krb: "This example could..."] be the
  474. first body part of a multipart/signed message [krb: add a comma] or the signed and/or
  475. encrypted payload of the application/pkcs7-mime body part. Lines
  476. prepended by "O: " are the outer header section. Lines prepended by
  477. "I: " are the inner header section. [krb: As above, this is structured oddly. Suggest a new paragraph.
  478. "Lines are prepended as follows:
  479. O: Outer Message Header Section
  480. I: Inner Message Header Section]
  481. Hoeneisen & Melnikov Expires January 10, 2021 [Page 14]
  482. Internet-Draft Header Protection S/MIME July 2020
  483. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  484. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
  485. O: Subject: Meeting at my place
  486. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  487. O: MIME-Version: 1.0
  488. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  489. O: protocol="application/pkcs7-signature";
  490. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  491. This is a multipart message in MIME format.
  492. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  493. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  494. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  495. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
  496. I: MIME-Version: 1.0
  497. I: MMHS-Primary-Precedence: 3
  498. I: Subject: Meeting at my place
  499. I: To: somebody@example.net
  500. I: X-Mailer: Isode Harrier Web Server
  501. I: Content-Type: text/plain; charset=us-ascii
  502. This is an important message that I don't want to be modified.
  503. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  504. Content-Transfer-Encoding: base64
  505. Content-Type: application/pkcs7-signature
  506. [[base-64 encoded signature]]
  507. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  508. The Outer Message Header Section is unprotected, while the remainder
  509. (Outer Message Body) is protected. The Outer Message Body consists
  510. of the Inner Message (Header Section and Body).
  511. The Inner Message Header Section is the same as (or a subset of) the
  512. Original Message Header Section (cf. Section 4.1.2).
  513. The Inner Message Body is the same as the Original Message Body.
  514. The Original Message itself may contain any MIME structure.
  515. 4.1.2. Inner Message Header Fields
  516. It is RECOMMENDED that the Inner Messages [krb: "Message"] contains all the [krb: remove "the"] Header
  517. Fields of the Original Message with the exception of the following
  518. Hoeneisen & Melnikov Expires January 10, 2021 [Page 15]
  519. Internet-Draft Header Protection S/MIME July 2020
  520. Header Field, which MUST NOT be included within the Inner Message nor
  521. within any other protected part of the message:
  522. o Bcc
  523. [[ TODO: Bcc handling needs to be further specified (see also
  524. Appendix A.1). Certain MUAs cannot properly decrypt messages with
  525. Bcc recipients. ]]
  526. 4.1.3. Wrapper
  527. The wrapper is a simple MIME Header Section followed by an empty line
  528. preceding the Inner Message (inside the Outer Message Body). The
  529. media type of the wrapper MUST be "message/RFC822" and MUST contain
  530. the Content-Type header field parameter "forwarded=no" as defined in
  531. [I-D.melnikov-iana-reg-forwarded]. The wrapper delimits
  532. unambiguously [krb: "unambiguously delimits"] the Inner Message from the rest of the message.
  533. 4.1.4. Outer Message Header Fields
  534. To maximize Privacy, it is strongly RECOMMENDED to follow the
  535. principle of Data Minimization (cf. Section 2.1).
  536. However, the Outer Message Header Section SHOULD contain the
  537. Essential Header Fields and, in addition, MUST contain the Header
  538. Fields of the MIME Header Section part to describe the encryption or
  539. signature as per [RFC8551].
  540. The following Header Fields are defined as the Essential Header
  541. Fields:
  542. o From
  543. o To (if present in the Original Message)
  544. o Cc (if present in the Original Message)
  545. o Bcc (if present in the Original Message, see also Section 4.1.2
  546. and Appendix A.1)
  547. o Date
  548. o Message-ID
  549. o Subject
  550. Further processing by the Submission Entity normally depends on part
  551. of these Header Fields, e.g. From and Date HFs are required by
  552. Hoeneisen & Melnikov Expires January 10, 2021 [Page 16]
  553. Internet-Draft Header Protection S/MIME July 2020
  554. [RFC5322]. Furthermore, not including certain Header Fields may
  555. trigger spam detection to flag the message and/or lead to user
  556. experience (UX) issues.
  557. For further Data Minimization, the value of the Subject Header Field
  558. SHOULD be obfuscated. In addition, the value of other Essential
  559. Header Fields MAY be obfuscated. Further Header Fields MAY be
  560. obfuscated, though simply not adding those to the Outer Message
  561. Header Section SHOULD be preferred over obfuscation. Header Field
  562. obfuscation is further specified in Section 4.1.4.1. Header Fields
  563. not obfuscated should contain the same values as in the Original
  564. Message.
  565. The MIME Header Section part is the collection of MIME Header Fields
  566. describing the following MIME structure as defined in [RFC2045]. A
  567. MIME Header Section part typically includes the following Header
  568. Fields:
  569. o Content-Type
  570. o Content-Transfer-Encoding
  571. o Content-Disposition
  572. The following example shows the MIME Header Section part of an S/MIME
  573. signed message (using application/pkcs7-mime with SignedData):
  574. MIME-Version: 1.0
  575. Content-Type: application/pkcs7-mime; smime-type=signed-data;
  576. name=smime.p7m
  577. Content-Transfer-Encoding: base64
  578. Content-Disposition: attachment; filename=smime.p7m
  579. Depending on the scenario, further Header Fields MAY be exposed in
  580. the Outer Message Header Section, which is NOT RECOMMENDED unless
  581. justified. Such Header Fields may include e.g.:
  582. o References
  583. o Reply-To
  584. o In-Reply-To
  585. Hoeneisen & Melnikov Expires January 10, 2021 [Page 17]
  586. Internet-Draft Header Protection S/MIME July 2020
  587. 4.1.4.1. Obfuscation of Outer Message Header Fields
  588. If the values of the following Outer Message Header Fields are
  589. obfuscated, those SHOULD assume the following values:
  590. * Subject: ...
  591. * Message-ID: <new randomly generated Message-ID>
  592. * Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
  593. [[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the
  594. same week. ]]
  595. In certain implementations also the From, To, and/or Cc Header Field
  596. MAY be obfuscated. Those may be replaced by e.g.
  597. o To: Obfuscated anonymous@anonymous.invalid [1]
  598. Such implementations may need to ensure that the Submission Entity
  599. has access to the content of these Header Fields in clear text and is
  600. capable of processing those. This is particularly relevant, if
  601. proprietary Submission Entities are used.
  602. A use case for obfuscation of all Outer Message Header Fields is
  603. mixnet networks, i.e. "onion routing" for email (e.g. [pEp.mixnet]).
  604. Note: It is for further study to what extent Header Field obfuscation
  605. adversely impacts spam filtering.
  606. 4.1.5. Receiving User Facing Message Header Fields
  607. The Receiving User Facing Message SHOULD be a verbatim copy of the
  608. Inner Message.
  609. 4.1.6. Header Field Flow
  610. The Following figure depicts the different message representations
  611. (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
  612. from:
  613. Hoeneisen & Melnikov Expires January 10, 2021 [Page 18]
  614. Internet-Draft Header Protection S/MIME July 2020
  615. OrigM InnerM Outer(S) OuterM(R) RUFM
  616. <Trace-HF>
  617. From (OrigM) = From
  618. To (OrigM) = To
  619. Cc (OrigM) = Cc
  620. Bcc (OrigM) = Bcc*
  621. Date (OrigM) = Date
  622. Message-ID (OrigM)= Message-ID
  623. Subject (new) = Subject
  624. <MIME-HSp> (new) = <MIME-HSp>
  625. PROTECTED: PROTECTED:
  626. <Wrapper> (new) = <Wrapper>
  627. From > From > From = From > From
  628. To > To > To = To > To
  629. Cc* > Cc > Cc = Cc > Cc
  630. Bcc*
  631. Date > Date > Date = Date > Date
  632. Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
  633. Subject > Subject > Subject = Subject > Subject
  634. <More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
  635. <MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
  636. <Body> > <Body> > <Body> = <Body> > <Body>
  637. <Signature>* (new)= <Signature>
  638. Legend:
  639. o OuterM(S): Outer Message (OuterM) at sending side (before handing
  640. it over to the Submission Entity)
  641. o OuterM(R): Outer Message at receiving side (as received by the
  642. last hop, before decryption and/or signature verification is
  643. applied to)
  644. o InnerM: Inner Message (that protection is applied to)
  645. o RUFM: Receiving User Facing Message
  646. o More-HF: Additional Header Fields (HF) in the Original Message
  647. (OrigM)
  648. o Wrapper: MIME Header Section; with media type (message/RFC822) to
  649. unambiguously delimit the inner message from the rest of the
  650. message.
  651. Hoeneisen & Melnikov Expires January 10, 2021 [Page 19]
  652. Internet-Draft Header Protection S/MIME July 2020
  653. o MIME-HSp: MIME Header Section part to describe the encryption or
  654. signature as per [RFC8551]
  655. o Trace-HF: Header Fields added in Transit (between sending and
  656. receiving side) as per [RFC5322]
  657. o >: taken over / copied from last column
  658. o =: propagates unchanged, unless something unusual (e.g. attack)
  659. happens
  660. o *: HF that is often not present (also further HFs, e.g. To, may
  661. not be present). If a HF is not present, naturally it can neither
  662. be taken over nor propagated.
  663. o (new) / (OrigM): HF or MIME-HSp is generated depending on the
  664. decision in Section 4.1.7.1, while '(new)' / '(OrigM)' designate
  665. the default.
  666. 4.1.7. Sending Side Message Processing
  667. For a protected message the following steps are applied before a
  668. message is handed over to the Submission Entity:
  669. 4.1.7.1. Step 1: Decide on Protection Level and Information Disclosure
  670. The entity applying protection to a message must decide:
  671. o Which Protection Level (signature and/or encryption) is applied to
  672. the message? This depends on user request and/or local policy as
  673. well as availability of cryptographic keys.
  674. o Which Header Fields of the Original Message shall be part of the
  675. Outer Message Header Section? This typically depends on local
  676. policy. By default the Essential Header Fields are part of the
  677. Outer Message Header Section; cf. Section 4.1.4.
  678. o Which of these Header Fields are to be obfuscated? This depends
  679. on local policy and/or specific Privacy requirements of the user.
  680. By default only the Subject Header Field is obfuscated; cf.
  681. Section 4.1.4.1.
  682. 4.1.7.2. Step 2: Compose the Outer Message Header Section
  683. Depending on the decision in Section 4.1.7.1, compose the Outer
  684. Message Header Section. (Note that this also includes the necessary
  685. MIME Header Section part for the following protection layer.)
  686. Hoeneisen & Melnikov Expires January 10, 2021 [Page 20]
  687. Internet-Draft Header Protection S/MIME July 2020
  688. Outer Header Fields that are not obfuscated should contain the same
  689. values as in the Original Message (except for MIME Header
  690. Section part, which depends on the protection level selected in
  691. Section 4.1.7.1).
  692. 4.1.7.3. Step 3: Apply Protection to the Original Message
  693. Depending on the Protection Level selected in Section 4.1.7.1, apply
  694. signature and/or encryption to the Original Message, including the
  695. wrapper (as per [RFC8551]), and set the result to the message as
  696. Outer Message Body.
  697. The resulting (Outer) Message is then typically handed over to the
  698. Submission Entity.
  699. [[ TODO: Example ]]
  700. 4.1.8. Receiving Side Message Processing
  701. When a protected message is received, the following steps are
  702. applied:
  703. 4.1.8.1. Step 1: Decrypt message and/or check signature
  704. Depending on the protection level, the received message is decrypted
  705. and/or its signature is checked as per [RFC8551].
  706. 4.1.8.2. Step 2: Construct the Receiving User Facing Message
  707. The Receiving User Facing Message is constructed according to
  708. Section 4.1.5.
  709. The resulting message is handed over for further processing, which
  710. typically involves rendering it for the user.
  711. Note: Further study is needed to determine whether or not the Outer
  712. Message Header Section, as received from the last hop, is preserved
  713. for the user, and if so, how this is to be achieved.
  714. 4.2. Backward Compatibility Use Cases
  715. 4.2.1. Receiving Side MIME-Conformant
  716. This section applies to the case where the sending side (fully)
  717. supports Header Protection as specified in this document, while the
  718. receiving side does not support this specification, but is MIME-
  719. conformant according to [RFC2045], ff. (cf. Section 3.1.2) and
  720. Section 3.1.2.1)
  721. Hoeneisen & Melnikov Expires January 10, 2021 [Page 21]
  722. Internet-Draft Header Protection S/MIME July 2020
  723. The sending side specification of the main use case (cf. {#main-use-
  724. case}}) MUST ensure that receiving sides, that do not support this
  725. specification, but are MIME-conformant according to [RFC2045], ff.
  726. can still recognize and display the Inner Message (or rather the
  727. RUFM) in such a way as to preserve any recursive structure, that is,
  728. displaying or offering to display the encapsulated data in accordance
  729. with its media type (cf. [RFC2049], Section 2).
  730. [[TODO: Verify once solution is stable and update last sentence ]]
  731. 4.2.2. Receiving Side Not MIME-Conformant
  732. This section applies to the case where the sending side (fully)
  733. supports Header Protection as specified in this document, while the
  734. receiving side neither supports this specification and *nor* is MIME-
  735. conformant according to [RFC2045], ff. (cf. {{uc-ia-backward-
  736. compatibility-use-cases}) and Section 3.1.2.2).
  737. [I-D.autocrypt-lamps-protected-headers] describes a possible way to
  738. achieve backward compatibility with existing S/MIME (and PGP/MIME)
  739. implementations that predate this specification and are not MIME-
  740. conformant (Legacy Display) either. It mainly focuses on email
  741. clients that do not render emails using header protection (in a user
  742. friendly manner) and may confuse the user. While this has been
  743. observed occasionally in PGP/MIME (cf. [RFC3156]), the extent of
  744. this problem with S/MIME implementations is still unclear. (Note: At
  745. this time, none of the samples in
  746. [I-D.autocrypt-lamps-protected-headers] apply header protection as
  747. specified in Section 3.1 of [RFC8551], which is wrapping as Media
  748. Type "message/RFC822".)
  749. Should serious backward compatibility issues with rendering at the
  750. receiver be discovered, the Legacy Display format described in
  751. [I-D.autocrypt-lamps-protected-headers] may serve as a basis to
  752. mitigate those issues (cf. Section 4.2).
  753. Another variant of backward compatibility has been implemented by pEp
  754. [I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has
  755. implemented this for PGP/MIME, but not yet S/MIME.
  756. 5. Security Considerations
  757. [[ TODO ]]
  758. Hoeneisen & Melnikov Expires January 10, 2021 [Page 22]
  759. Internet-Draft Header Protection S/MIME July 2020
  760. 6. Privacy Considerations
  761. [[ TODO ]]
  762. 7. IANA Considerations
  763. This document requests no action from IANA.
  764. [[ RFC Editor: This section may be removed before publication. ]]
  765. 8. Acknowledgments
  766. The authors would like to thank the following people who have
  767. provided helpful comments and suggestions for this document: Berna
  768. Alp, Claudio Luck, Daniel Kahn Gillmor, David Wilson, Hernani
  769. Marques, Krista Bennett, Kelly Bristol, Robert Williams, Sofia
  770. Balicka, Steve Kille, Volker Birk, and Wei Chuang.
  771. 9. References
  772. 9.1. Normative References
  773. [I-D.ietf-lamps-header-protection-requirements]
  774. Melnikov, A. and B. Hoeneisen, "Problem Statement and
  775. Requirements for Header Protection", draft-ietf-lamps-
  776. header-protection-requirements-01 (work in progress),
  777. October 2019.
  778. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
  779. Extensions (MIME) Part One: Format of Internet Message
  780. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
  781. <https://www.rfc-editor.org/info/rfc2045>.
  782. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
  783. Extensions (MIME) Part Two: Media Types", RFC 2046,
  784. DOI 10.17487/RFC2046, November 1996,
  785. <https://www.rfc-editor.org/info/rfc2046>.
  786. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
  787. Extensions (MIME) Part Five: Conformance Criteria and
  788. Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
  789. <https://www.rfc-editor.org/info/rfc2049>.
  790. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  791. Requirement Levels", BCP 14, RFC 2119,
  792. DOI 10.17487/RFC2119, March 1997,
  793. <https://www.rfc-editor.org/info/rfc2119>.
  794. Hoeneisen & Melnikov Expires January 10, 2021 [Page 23]
  795. Internet-Draft Header Protection S/MIME July 2020
  796. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
  797. DOI 10.17487/RFC5322, October 2008,
  798. <https://www.rfc-editor.org/info/rfc5322>.
  799. [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
  800. Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
  801. Message Specification", RFC 8551, DOI 10.17487/RFC8551,
  802. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
  803. 9.2. Informative References
  804. [I-D.autocrypt-lamps-protected-headers]
  805. Einarsson, B., juga, j., and D. Gillmor, "Protected
  806. Headers for Cryptographic E-mail", draft-autocrypt-lamps-
  807. protected-headers-02 (work in progress), December 2019.
  808. [I-D.melnikov-iana-reg-forwarded]
  809. Melnikov, A. and B. Hoeneisen, "IANA Registration of
  810. Content-Type Header Field Parameter 'forwarded'", draft-
  811. melnikov-iana-reg-forwarded-00 (work in progress),
  812. November 2019.
  813. [I-D.pep-email]
  814. Marques, H., "pretty Easy privacy (pEp): Email Formats and
  815. Protocols", draft-marques-pep-email-02 (work in progress),
  816. October 2018.
  817. [pEp.mixnet]
  818. pEp Foundation, "Mixnet", June 2020,
  819. <https://dev.pep.foundation/Mixnet>.
  820. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
  821. "MIME Security with OpenPGP", RFC 3156,
  822. DOI 10.17487/RFC3156, August 2001,
  823. <https://www.rfc-editor.org/info/rfc3156>.
  824. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
  825. FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
  826. <https://www.rfc-editor.org/info/rfc4949>.
  827. [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
  828. "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
  829. RFC 6376, DOI 10.17487/RFC6376, September 2011,
  830. <https://www.rfc-editor.org/info/rfc6376>.
  831. [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
  832. STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
  833. <https://www.rfc-editor.org/info/rfc6409>.
  834. Hoeneisen & Melnikov Expires January 10, 2021 [Page 24]
  835. Internet-Draft Header Protection S/MIME July 2020
  836. [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
  837. Authorizing Use of Domains in Email, Version 1", RFC 7208,
  838. DOI 10.17487/RFC7208, April 2014,
  839. <https://www.rfc-editor.org/info/rfc7208>.
  840. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
  841. Message Authentication, Reporting, and Conformance
  842. (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
  843. <https://www.rfc-editor.org/info/rfc7489>.
  844. 9.3. URIs
  845. [1] mailto:anonymous@anonymous.invalid
  846. Appendix A. Additional information
  847. A.1. Stored Variants of Messages with Bcc
  848. Messages containing at least one recipient address in the Bcc header
  849. field may appear in up to three different variants:
  850. 1. The message for the recipient addresses listed in To or Cc header
  851. fields, which must not include the Bcc header field neither for
  852. signature calculation nor for encryption.
  853. 2. The message(s) sent to the recipient addresses in the Bcc header
  854. field, which depends on the implementation:
  855. a) One message for each recipient in the Bcc header field
  856. separately, with a Bcc header field containing only the address
  857. of the recipient it is sent to.
  858. b) The same message for each recipient in the Bcc header field
  859. with a Bcc header field containing an indication such as
  860. "Undisclosed recipients", but no addresses.
  861. c) The same message for each recipient in the Bcc header field
  862. which does not include a Bcc header field (this message is
  863. identical to 1. / cf. above).
  864. 3. The message stored in the 'Sent'-Folder of the sender, which
  865. usually contains the Bcc unchanged from the original message,
  866. i.e., with all recipient addresses.
  867. The most privacy preserving method of the alternatives (2a, 2b, and
  868. 2c) is to standardize 2a, as in the other cases (2b and 2c),
  869. information about hidden recipients is revealed via keys. In any
  870. Hoeneisen & Melnikov Expires January 10, 2021 [Page 25]
  871. Internet-Draft Header Protection S/MIME July 2020
  872. case, the message has to be cloned and adjusted depending on the
  873. recipient.
  874. Appendix B. Document Changelog
  875. [[ RFC Editor: This section is to be removed before publication ]]
  876. o draft-ietf-lamps-header-protection-00
  877. * Initial version (text partially taken over from
  878. [I-D.ietf-lamps-header-protection-requirements]
  879. Appendix C. Open Issues
  880. [[ RFC Editor: This section should be empty and is to be removed
  881. before publication. ]]
  882. o Ensure "protected header" (Ex-Memory-Hole) option is (fully)
  883. compliant with the MIME standard, in particular also [RFC2046],
  884. Section 5.1. (Multipart Media Type) Section 4.1.1.2.
  885. o Decide on format of obfuscated HFs, in particular Date HF
  886. (Section 4.1.4.1)
  887. o Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1)
  888. o More examples (e.g. in Section 4.1.7)
  889. o Should Outer Message Header Section (as received) be preserved for
  890. the user? (Section 4.1.8.2)
  891. o Change adding Content-Type header field parameter "forwarded" from
  892. SHOULD to MUST (Section 4.1.3)?
  893. o Decide on whether or not merge requirements from
  894. [I-D.ietf-lamps-header-protection-requirements] into this
  895. document.
  896. o Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
  897. merge into this document.
  898. o Enhance Introduction and Problem Statement sections
  899. o Decide on whether or not specification for more legacy HP
  900. requirements should be added to this document
  901. Hoeneisen & Melnikov Expires January 10, 2021 [Page 26]
  902. Internet-Draft Header Protection S/MIME July 2020
  903. o Verify ability to distinguish between Messages with Header
  904. Protection as specified in this document and legacy clients and
  905. update Section 3.1 accordingly.
  906. o Verify simple backward compatibility case (Receiving Side MIME-
  907. Conformant) is working; once solution is stable and update
  908. paragraphs in {#uc-ia-bc-receiving-side-mime-conformant}} and
  909. Section 4.2.1 accordingly.
  910. o Improve definitions in Section 3.2
  911. o Privacy Considerations Section 6
  912. o Security Considerations Section 5
  913. Authors' Addresses
  914. Bernie Hoeneisen
  915. pEp Foundation
  916. Oberer Graben 4
  917. CH-8400 Winterthur
  918. Switzerland
  919. Email: bernie.hoeneisen@pep.foundation
  920. URI: https://pep.foundation/
  921. Alexey Melnikov
  922. Isode Ltd
  923. 14 Castle Mews
  924. Hampton, Middlesex TW12 2NP
  925. UK
  926. Email: alexey.melnikov@isode.com
  927. Hoeneisen & Melnikov Expires January 10, 2021 [Page 27]