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.

1160 lines
38 KiB

3 years ago
2 years ago
2 years ago
3 years ago
  1. ---
  2. coding: utf-8
  3. title: "Problem Statement and Requirements for Header Protection"
  4. abbrev: Header Protection requirements
  5. docname: draft-ietf-lamps-header-protection-requirements-02
  6. category: info
  7. stand_alone: yes
  8. pi: [toc, sortrefs, symrefs, comments]
  9. author:
  10. {::include ../shared/author_tags/alexey_melnikov.mkd}
  11. {::include ../shared/author_tags/bernie_hoeneisen.mkd}
  12. #{::include ../shared/author_tags/daniel_kahn_gillmor.mkd}
  13. normative:
  14. # RFC822:
  15. # RFC1847:
  16. # RFC1341:
  17. RFC2045: # MIME part 1 #
  18. RFC5322: # SMTP #
  19. RFC8551: # S/MIME #
  20. informative:
  21. # RFC8301:
  22. # RFC8463:
  23. # RFC2046:
  24. # RFC3156:
  25. RFC3501: # IMAP #
  26. RFC4949: # Internet Security Glossary #
  27. RFC4880: # PGP #
  28. # RFC5321:
  29. # RFC5490:
  30. RFC6376: # DKIM #
  31. RFC6532: # internationalized email headers #
  32. RFC7208: # SPF #
  33. # RFC7258:
  34. # RFC7435:
  35. RFC7489: # DMARC #
  36. # RFC7942:
  37. # I-D.melnikov-lamps-header-protection:
  38. # I-D.birk-pep:
  39. I-D.marques-pep-email:
  40. I-D.luck-lamps-pep-header-protection:
  41. # I-D.marques-pep-handshake:
  42. # I-D.birk-pep-trustwords:
  43. # I-D.marques-pep-rating:
  44. --- abstract
  45. Privacy and security issues with email header protection in S/MIME
  46. have been identified for some time. However, the desire to fix these
  47. issues has only recently been expressed in the IETF LAMPS Working
  48. Group. The existing S/MIME specification is likely to be updated
  49. regarding header protection.
  50. This document describes the problem statement, generic use cases, and
  51. requirements of header protection.
  52. --- middle
  53. # Introduction
  54. A range of protocols for the protection of electronic mail (email)
  55. exist, which allow to assess the authenticity and integrity of the
  56. email headers section or selected header fields (HF) from the
  57. domain-level perspective, specifically DomainKeys Identified Mail
  58. (DKIM) {{RFC6376}} and Sender Policy Framework (SPF) {{RFC7208}}, and
  59. Domain-based Message Authentication, Reporting, and Conformance
  60. (DMARC) {{RFC7489}}. These protocols, while essential to responding to
  61. a range of attacks on email, do not offer full end-to-end protection
  62. to the header section and are not capable of providing privacy for the
  63. information contained therein.
  64. The need for means of Data Minimization, which includes data sparseness
  65. and hiding all technically concealable information whenever possible,
  66. has grown in importance over the past several years.
  67. A standard for end-to-end protection of the email header section
  68. exists for S/MIME version 3.1 and later. (cf. {{RFC8551}}):
  69. > In order to protect outer, non-content-related message header fields
  70. > (for instance, the "Subject", "To", "From", and "Cc" fields), the
  71. > sending client MAY wrap a full MIME message in a message/rfc822
  72. > wrapper in order to apply S/MIME security services to these header
  73. > fields.
  74. No mechanism for header protection (HP) has been standardized for PGP
  75. (Pretty Good Privacy) {{RFC4880}} yet.
  76. Several varying implementations of end-to-end protections for email
  77. header sections exist, though the total number of such implementations
  78. appears to be rather low.
  79. Some LAMPS WG participants expressed the opinion that whatever
  80. mechanism will be chosen, it should not be limited to S/MIME, but
  81. also applicable to PGP/MIME.
  82. This document describes the problem statement ({{problem-statement}}),
  83. generic use cases ({{use-cases}}) and requirements for Header
  84. Protection ({{requirements}}). In {{implementation-considerations}},
  85. possible solutions to address the challenge and some best practices
  86. are collected. In any case, the final solution is to be determined by
  87. the IETF LAMPS WG.
  88. {::include ../shared/text-blocks/key-words-rfc2119.mkd}
  89. {::include ../shared/text-blocks/terms-intro.mkd}
  90. * Header Protection (HP): cryptographic protection of email Header
  91. Sections for signatures and encryption
  92. * Header Field (HF): cf. {{RFC5322}}
  93. * Header Section (HS): cf. {{RFC5322}}
  94. <!-- {::include ../shared/text-blocks/handshake.mkd} -->
  95. <!-- {::include ../shared/text-blocks/trustwords.mkd} -->
  96. <!-- {::include ../shared/text-blocks/tofu.mkd} -->
  97. {::include ../shared/text-blocks/mitm.mkd}
  98. * 'Signature and encryption', 'signature only' or 'encryption only'
  99. are further explained in {{protection-levels}}.
  100. # Problem Statement {#problem-statement}
  101. The LAMPS charter contains the following Work Item:
  102. > Update the specification for the cryptographic protection of email
  103. > headers -- both for signatures and encryption -- to improve the
  104. > implementation situation with respect to privacy, security, usability
  105. > and interoperability in cryptographically-protected electronic mail.
  106. > Most current implementations of cryptographically-protected electronic
  107. > mail protect only the body of the message, which leaves significant
  108. > room for attacks against otherwise-protected messages.
  109. In the following a set of challenges to be addressed:
  110. \[\[ TODO: enhance this section, add more items to the following \]\]
  111. ## Privacy
  112. * Data Minimization, which includes data sparseness and hiding all
  113. technically concealable information whenever possible
  114. ## Security
  115. * MITM attacks (cf. {{RFC4949}})
  116. ## Usability
  117. * User interaction / User experience
  118. ## Interoperability
  119. * Interoperability with {{RFC8551}} implementations
  120. # Use Cases {#use-cases}
  121. In the following a list of the generic use cases that need to be
  122. addressed for messages with Header Protection (HP). These use cases
  123. apply independently of whether S/MIME, PGP/MIME or any other
  124. technology is used to achieve HP.
  125. ## Interactions
  126. The main interaction case for Header Protection (HP) is:
  127. {::include ../shared/fence-line.mkd}
  128. 1) Both peers (sending and receiving side) fully support HP
  129. {::include ../shared/fence-line.mkd}
  130. For backward compatibility of legacy clients -- unaware of any HP -- the
  131. following intermediate interactions need to be considered as well:
  132. {::include ../shared/fence-line.mkd}
  133. 2) The sending side fully supports HP, while the receiving side does
  134. not support any HP
  135. 3) The sending side does not support any HP, while the receiving
  136. side fully supports HP
  137. 4) Neither the sending side nor the receiving side supports any HP
  138. (trivial case)
  139. {::include ../shared/fence-line.mkd}
  140. The following intermediate use cases may need to be considered as well
  141. for backward compatibility with legacy HP systems, such as S/MIME
  142. version 3.1 and later (cf. {{RFC8551}}), in the following designated
  143. as legacy HP:
  144. {::include ../shared/fence-line.mkd}
  145. 5) The sending side fully supports HP, while the receiving side
  146. supports legacy HP only
  147. 6) The sending side supports legacy HP only, while the receiving side
  148. fully supports HP
  149. 7) Both peers (sending and receiving side) support legacy HP only
  150. 8) The sending side supports legacy HP only, while the receiving side
  151. does not support any HP
  152. 9) The sending side does not support any HP, while the receiving side
  153. supports legacy HP only
  154. {::include ../shared/fence-line.mkd}
  155. Note: It is to be decided whether to ensure legacy HP systems do not
  156. conflict with any new solution for HP at all or whether (and to which
  157. degree) backward compatibility to legacy HP systems shall be
  158. maintained.
  159. <!-- krb: suggested to replace by:
  160. "The compatibility of legacy HP systems with new solutions, and
  161. how to handle issues surrounding future maintenance for these
  162. legacy systems, will be decided by the LAMPS WG."
  163. -->
  164. \[\[ TODO: Decide in which form legacy HP requirements should remain
  165. in this document. \]\]
  166. <!--
  167. \[\[ TODO:
  168. AM: Do we need to list all legacy related case here? It
  169. seems to clutter this document (problem statement/overview), even if
  170. it would be worth talking about these cases in the solution
  171. document.
  172. HB: I would leave them in for completeness. but lower prio. (Note: In
  173. case we remove / change them, it affects the requirements section of
  174. the document)
  175. \]\]
  176. -->
  177. ## Protection Levels {#protection-levels}
  178. The following protection levels need to be considered:
  179. a) Signature and encryption
  180. Messages containing a cryptographic signature which
  181. are also encrypted.
  182. Sending and receiving side SHOULD implement 'signature and
  183. encryption', which is the default to use on the sending side.
  184. b) Signature only
  185. Messages containing a cryptographic signature, but which no
  186. encryption is applied to.
  187. <!--
  188. a cryptographic signature usually within a multipart/signed or
  189. application/pkcs7-mime Content-Type, which doesn't contain any
  190. encrypted layer.
  191. -->
  192. Certain implementations MAY decide to send 'signature only'
  193. messages, depending on the circumstances and customer requirements.
  194. Sending and Receiving sides SHOULD implement 'signature only'.
  195. c) Encryption only
  196. Messages that encryption is applied to which do not contain a
  197. cryptographic signature.
  198. 'Encryption only' is NOT RECOMMENDED on the sending side, however
  199. the receiving side needs certain guidelines on how to process
  200. received 'encrypted only' messages
  201. # Requirements {#requirements}
  202. The following is a list of requirements that need to be addressed
  203. independently of whether S/MIME, PGP/MIME or any other technology is
  204. used to apply HP to.
  205. ## General Requirements
  206. Note: This subsection lists the requirements to address use case 1)
  207. (cf. {{interactions}}).
  208. {::include ../shared/fence-line.mkd}
  209. G1: Define the HP format for all protection levels (cf. above), which
  210. includes MIME structure, Content-Type (including all parameters,
  211. such as "charset" and "name"), Content-Disposition (including all
  212. parameters, such as "filename"), and Content-Transfer-Encoding.
  213. G2: To foster wide implementation of the new solution, it shall be
  214. easily implementable. Unless needed for maximizing protection and
  215. privacy, existing implementations shall not require substantial
  216. changes in the existing code base. In particular also MIME
  217. libraries widely used shall not need to be changed to comply with
  218. the new mechanism for HP.
  219. G3: There SHOULD be a single format that covers all protection levels
  220. (cf. above).
  221. [[ TODO: Should this one remain in the document?]]
  222. G4: Ensure that man-in-the-middle attack (MITM, cf. [RFC4949]), in
  223. particular downgrade attacks, are mitigated to the greatest extent
  224. possible.
  225. {::include ../shared/fence-line.mkd}
  226. ### Sending Side
  227. {::include ../shared/fence-line.mkd}
  228. GS1: Determine which Header Fields (HFs) should or must be protected
  229. for 'signature only' emails at a minimum.
  230. GS2: Determine which HFs should or must be sent in clear text (i.e.,
  231. included in the outer header) for emails with (signature and)
  232. encryption applied.
  233. GS3: Determine which HFs should not or must not be sent in clear text
  234. (i.e., not be included in the outer header) of an email with
  235. (signature and) encryption applied.
  236. GS4: Determine which HFs to not include to any HP part (e.g. Bcc).
  237. {::include ../shared/fence-line.mkd}
  238. ### Receiving Side
  239. {::include ../shared/fence-line.mkd}
  240. GR1: Determine how HFs should be displayed to the user in case of
  241. conflicting information between the protected and unprotected
  242. HFs.
  243. GR2: Ensure that man-in-the-middle attacks (MITM, cf. [RFC4949]), in
  244. particular downgrade attacks, can be detected.
  245. GR3: Define how emails that 'encryption only' was applied to
  246. are to be treated.
  247. {::include ../shared/fence-line.mkd}
  248. ## Additional Requirements for Backward-Compatibility With Legacy Clients Unaware of Header Protection
  249. Note: This sub-section addresses the use cases 2) - 4) (cf. {{interactions}})
  250. {::include ../shared/fence-line.mkd}
  251. B1: Define a means to distinguish between forwarded emails and
  252. encapsulated emails using new HP mechanism.
  253. {::include ../shared/fence-line.mkd}
  254. ### Sending side
  255. {::include ../shared/fence-line.mkd}
  256. BS1: Define how full HP support can be indicated to outgoing
  257. emails.
  258. BS2: Define how full HP support of the receiver can be detected or
  259. derived.
  260. BS3: Ensure a HP-unaware receiving side easily can display the
  261. "Subject" HF to the user.
  262. {::include ../shared/fence-line.mkd}
  263. ### Receiving side
  264. {::include ../shared/fence-line.mkd}
  265. BR1: Define how full HP support can be detected in incoming emails.
  266. {::include ../shared/fence-line.mkd}
  267. ## Additional Requirements for Backward-Compatibility with Legacy Header Protection Systems (if supported)
  268. Note: This sub-section addresses the use cases 5) - 9) (cf. {{interactions}}).
  269. {::include ../shared/fence-line.mkd}
  270. LS1: Depending on the solution, define a means to distinguish between
  271. forwarded emails, legacy encapsulated emails, and
  272. encapsulated emails using new HP mechanism.
  273. LS2: The solution should be backward compatible to existing solutions
  274. and aim to minimize the implementation effort to include support
  275. for existing solutions.
  276. {::include ../shared/fence-line.mkd}
  277. ### Sending Side
  278. {::include ../shared/fence-line.mkd}
  279. LSS1: Determine how legacy HP support can be indicated to outgoing
  280. emails.
  281. LSS2: Determine how legacy HP support of the receiver can be detected
  282. or derived.
  283. {::include ../shared/fence-line.mkd}
  284. ### Receiving Side
  285. {::include ../shared/fence-line.mkd}
  286. LSR1: Determine how legacy HP support can be detected in incoming
  287. emails.
  288. {::include ../shared/fence-line.mkd}
  289. # Security Considerations
  290. This document talks about UI considerations, including security
  291. considerations, when processing messages protecting Header Fields.
  292. One of the goals of this document is to specify UI for displaying such
  293. messages which is less confusing/misleading for the end-user and thus
  294. more secure.
  295. The document does not define a new protocol, and thus does not create
  296. any new security concerns not already covered by S/MIME {{RFC8551}},
  297. MIME [RFC2045] and Email {{RFC5322}} in general.
  298. <!-- Suggestion to replace above paragraph:
  299. This document does not define new protocols, and thus does not
  300. create new security concerns in and of itself. Existing security
  301. concerns addressed in S/MIME {{RFC8551}}, MIME {{RFC2045}}, and
  302. Email {{RFC5322}} still apply to header fields and should be
  303. taken into consideration.
  304. -->
  305. # Privacy Considerations
  306. \[\[ TODO \]\]
  307. # IANA Considerations
  308. This document requests no action from IANA.
  309. \[\[ RFC Editor: This section may be removed before publication. \]\]
  310. # Acknowledgments
  311. The authors would like to thank the following people who have provided
  312. helpful comments and suggestions for this document: David Wilson,
  313. Kelly Bristol, Robert Williams, Steve Kille, and Wei Chuang.
  314. Essential parts of {{I-D.luck-lamps-pep-header-protection}} have been
  315. merged into this document. Special thanks to its author Claudio Luck.
  316. For further Acknowledgments, please refer to Acknowledgments section
  317. of {{I-D.luck-lamps-pep-header-protection}}.
  318. David Wilson came up with the idea of defining a new Content-Type
  319. header field parameter to distinguish forwarded messages from inner
  320. header field protection constructs.
  321. --- back
  322. <!-- =========================================================================== -->
  323. # Implementation Considerations {#implementation-considerations}
  324. \[\[ Note: Please be advised that this part of the document is early
  325. work-in-progress. \]\]
  326. This {{implementation-considerations}} contains additional information
  327. and considerations regarding the implementation. Although not
  328. (strictly) part of the requirements, this is useful to better
  329. understand them. Parts of the text in this
  330. {{implementation-considerations}} will likely be moved to the upcoming
  331. implementation document.
  332. ## Options to Achieve Header Protection
  333. The following are current options for addressing Email Header
  334. Protection. The IETF LAMPS WG may choose from these options in order
  335. to update {{RFC8551}}.
  336. ### Option 1: Memory Hole {#memory-hole}
  337. The Memory Hole approach works by copying the normal message header
  338. fields into the MIME header section of the top level protected body
  339. part. Since the MIME body part header section is itself covered by
  340. the protection mechanisms (signature and/or encryption) it shares the
  341. protections of the message body.
  342. \[\[ TODO<!--(DKG)-->: add more information on memory hole ]\]
  343. ### Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping}
  344. Wrapping with message/rfc822 (or message/global) works by copying the
  345. normal message header fields into the MIME header section of the top
  346. level protect body part
  347. \[\[ TODO: consider rephrasing, as not only the header fields is copied,
  348. but also the content.\]\]
  349. <!--
  350. \[\[ TODO:
  351. HB: Not sure this is well expressed: In option 2 the whole
  352. message is copied into the MIME body part as message/rfc822 element.
  353. AM: You might be right, but I think looking at example message helps?
  354. \]\]
  355. -->
  356. and then prepending them with "Content-Type: message/rfc822;
  357. forwarded=no\r\n" or "Content-Type: message/global; forwarded=no\r\n",
  358. where \r\n is US-ASCII CR followed by US-ASCII LF (see also
  359. {{content-type-parameter-forwarded}}). Since the MIME body part
  360. header section is itself covered by the protection mechanisms
  361. (signature and/or encryption) it shares the protections of the message
  362. body.
  363. #### Content-Type Parameter "forwarded" {#content-type-parameter-forwarded}
  364. This section outlines how the new "forwarded" Content-Type header
  365. field parameter could be defined (probably in a separate document)
  366. and how header section wrapping works:
  367. This document defines a new Content-Type header field parameter
  368. [RFC2045] with name "forwarded". The parameter value is case-
  369. insensitive and can be either "yes" or "no". (The default value being
  370. "yes"). The parameter is only meaningful with media type
  371. "message/rfc822" and "message/global" {{RFC6532}} when used within
  372. S/MIME or PGP/MIME signed or encrypted body parts. The value "yes"
  373. means that the message nested inside "message/rfc822"
  374. ("message/global") is a forwarded message and not a construct created
  375. solely to protect the inner header section.
  376. Instructions in {{RFC8551}} describing how to protect the Email message
  377. header section {{RFC5322}}, by wrapping the message inside a message/
  378. rfc822 container {{RFC2045}} are thus updated to read:
  379. > In order to protect outer, non-content-related message header
  380. > fields (for instance, the "Subject", "To", "From", and "Cc"
  381. > fields), the sending client MAY wrap a full MIME message in a
  382. > message/rfc822 wrapper in order to apply S/MIME security services
  383. > to these header fields. It is up to the receiving client to
  384. > decide how to present this "inner" header section along with the
  385. > unprotected "outer" header section.
  386. > When an S/MIME message is received, if the top-level protected
  387. > MIME entity has a Content-Type of message/rfc822 or message/global
  388. > without the "forwarded" parameter or with the "forwarded"
  389. > parameter set to "no", it can be assumed that the intent was to
  390. > provide header protection. This entity SHOULD be presented as the
  391. > top-level message, taking into account header section merging
  392. > issues as previously discussed.
  393. ### Option 2.1: Progressive Header Disclosure {#progressive-header-disclosure}
  394. This option is similar to Option 2 (cf. {{rfc822-wrapping}}). It also
  395. makes use the Content-Type parameter "forwarded"
  396. (cf. {{content-type-parameter-forwarded}}).
  397. pEp for email {{I-D.marques-pep-email}} defines a fixed MIME structure
  398. for its innermost message structure. Security comes just next after
  399. privacy in pEp, for which reason the application of signatures without
  400. encryption to messages in transit is not considered purposeful. pEp
  401. for email, either expects to transfer messages in cleartext without
  402. signature or encryption, or transfer them encrypted and with enclosed
  403. signature and necessary public keys so that replies can be immediately
  404. upgraded to encrypted messages.
  405. The pEp message format is equivalent to the S/MIME standard in
  406. ensuring header protection, in that the whole message is protected
  407. instead, by wrapping it and providing cryptographic services to the
  408. whole original message. However, for the purpose of allowing the
  409. insertion of public keys, the root entity of the protected
  410. message is thus nested once more into an additional multipart/mixed
  411. MIME entity. The current pEp proposal is for PGP/MIME, while an
  412. extension to S/MIME is also on the roadmap.
  413. pEp has also implemented the above (in
  414. {{content-type-parameter-forwarded}}) described Content-Type parameter
  415. "forwarded" to distinguish between encapsulated and forwarded emails.
  416. More information on progressive header disclosure can be found in
  417. {{I-D.luck-lamps-pep-header-protection}}.
  418. <!-- HB: preserved as commented out for the moment, as we may re-use part of this
  419. pEp (pretty Easy privacy) {{I-D.birk-pep}} for email
  420. {{I-D.marques-pep-email}} already implements an option quite similar
  421. to Option 2, adapting the S/MIME standards to PGP/MIME (cf.
  422. {{progressive-header-disclosure}}, ff.). Existing
  423. implementations of pEp have also added inbound support for "Memory
  424. Hole" referred to above as Option 1, thus being able to study the
  425. differences and the implementer's challenges.
  426. Interoperability and implementation symmetry between PGP/MIME and S/MIME is
  427. planned by pEp, but still in an early stage of development.
  428. -->
  429. <!-- HB: preserved as commented out for the moment, as we may re-use part of this
  430. and describes progressive header disclosure as
  431. implemented in the "pEp message format version 2". This format
  432. inherently offers header protection, and may be implemented
  433. independently by mail user agents otherwise not conforming to pEp
  434. standards ({{progressive-header-disclosure}}, ff.).
  435. -->
  436. ### Examples
  437. Examples in subsequent sections assume that an email client is trying
  438. to protect (sign) the following initial message:
  439. {::include ../shared/fence-line.mkd}
  440. Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  441. From: "Alexey Melnikov" <alexey.melnikov@example.net>
  442. Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  443. MIME-Version: 1.0
  444. MMHS-Primary-Precedence: 3
  445. Subject: Meeting at my place
  446. To: somebody@example.net
  447. X-Mailer: Isode Harrier Web Server
  448. Content-Type: text/plain; charset=us-ascii
  449. This is an important message that I don't want to be modified.
  450. Without message header protection the corresponding signed message
  451. might look like this. (Lines prepended by "O: " are the outer
  452. header.)
  453. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  454. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  455. O: Subject: Meeting at my place
  456. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  457. O: MIME-Version: 1.0
  458. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  459. O: protocol="application/pkcs7-signature";
  460. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  461. This is a multipart message in MIME format.
  462. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  463. Content-Type: text/plain; charset=us-ascii
  464. This is an important message that I don't want to be modified.
  465. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  466. Content-Transfer-Encoding: base64
  467. Content-Type: application/pkcs7-signature
  468. [[base-64 encoded signature]]
  469. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  470. {::include ../shared/fence-line.mkd}
  471. #### Option 1: Memory Hole {#memory-hole-example}
  472. The following example demonstrates how header section and payload of
  473. a protect body part might look like. For example, this will be the
  474. first body part of a multipart/signed message 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.
  478. {::include ../shared/fence-line.mkd}
  479. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  480. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  481. O: Subject: Meeting at my place
  482. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  483. O: MIME-Version: 1.0
  484. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  485. O: protocol="application/pkcs7-signature";
  486. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  487. This is a multipart message in MIME format.
  488. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  489. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  490. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  491. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  492. I: MIME-Version: 1.0
  493. I: MMHS-Primary-Precedence: 3
  494. I: Subject: Meeting at my place
  495. I: To: somebody@example.net
  496. I: X-Mailer: Isode Harrier Web Server
  497. I: Content-Type: text/plain; charset=us-ascii
  498. This is an important message that I don't want to be modified.
  499. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  500. Content-Transfer-Encoding: base64
  501. Content-Type: application/pkcs7-signature
  502. [[base-64 encoded signature]]
  503. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  504. {::include ../shared/fence-line.mkd}
  505. \[\[ TODO (AM): HB: Not sure whether the Outer Subject HF is replaced
  506. by "Encrypted Message" (or alike). Please verify. \]\]
  507. #### Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping-example}
  508. The following example demonstrates how header section and payload of
  509. a protect body part might look like. For example, this will be the
  510. first body part of a multipart/signed message or the signed and/or
  511. encrypted payload of the application/pkcs7-mime body part. Lines
  512. prepended by "O: " are the outer header section. Lines prepended by
  513. "I: " are the inner header section. Lines prepended by "W: " are the
  514. wrapper.
  515. {::include ../shared/fence-line.mkd}
  516. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  517. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  518. O: Subject: Meeting at my place
  519. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  520. O: MIME-Version: 1.0
  521. O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  522. O: protocol="application/pkcs7-signature";
  523. O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  524. This is a multipart message in MIME format.
  525. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  526. W: Content-Type: message/rfc822; forwarded=no
  527. W:
  528. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  529. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  530. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  531. I: MIME-Version: 1.0
  532. I: MMHS-Primary-Precedence: 3
  533. I: Subject: Meeting at my place
  534. I: To: somebody@example.net
  535. I: X-Mailer: Isode Harrier Web Server
  536. I: Content-Type: text/plain; charset=us-ascii
  537. This is an important message that I don't want to be modified.
  538. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  539. Content-Transfer-Encoding: base64
  540. Content-Type: application/pkcs7-signature
  541. [[base-64 encoded signature]]
  542. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  543. {::include ../shared/fence-line.mkd}
  544. #### Option 2.1 Progressive Header Disclosure {#progressive-header-disclosure-example}
  545. The following example demonstrates how header section and payload of a
  546. protect body part might look like. For example, this will be the
  547. first body part of a multipart/signed message or the signed and
  548. encrypted payload of the application/pkcs7-mime body part. Lines
  549. prepended by "O: " are the outer header section. Lines prepended by
  550. "I: " are the inner header section. Lines prepended by "W: " are the
  551. wrapper.
  552. The main difference compared to Option 2 is an additional
  553. multipart/mixed Content-Type containing the original message (as a
  554. whole) and the public key (of the sender).
  555. Note: This example is derived from the pEp's PGP/MIME implementation
  556. and adjusted to the above S/MIME examples. The pEp implementations do
  557. not support S/MIME yet; therefore the following can serve no more as
  558. for illustrative purpose. Specific examples can be found in
  559. {{I-D.luck-lamps-pep-header-protection}}.
  560. <!-- TODO: Update to email draft, once fixed -->
  561. {::include ../shared/fence-line.mkd}
  562. O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  563. O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  564. O: Subject: Meeting at my place
  565. O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  566. W: MIME-Version: 1.0
  567. W: Content-Type: multipart/mixed;
  568. W: boundary="6b8b4567327b23c6643c986966334873"
  569. W:
  570. W: --6b8b4567327b23c6643c986966334873
  571. W: Content-Type: message/rfc822; forwarded="no"
  572. W:
  573. I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  574. I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  575. I: Subject: Meeting at my place
  576. I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  577. I: MIME-Version: 1.0
  578. I: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  579. I: protocol="application/pkcs7-signature";
  580. I: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
  581. This is a multipart message in MIME format.
  582. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  583. Content-Type: text/plain; charset=us-ascii
  584. This is an important message that I don't want to be modified.
  585. --.cbe16d2a-e1a3-4220-b821-38348fc97237
  586. Content-Transfer-Encoding: base64
  587. Content-Type: application/pkcs7-signature
  588. [[base-64 encoded signature]]
  589. --.cbe16d2a-e1a3-4220-b821-38348fc97237--
  590. W: --6b8b4567327b23c6643c986966334873
  591. W: Content-Type: application/pgp-keys
  592. W: Content-Disposition: attachment; filename="pEpkey.asc"
  593. W:
  594. -----BEGIN PGP PUBLIC KEY BLOCK-----
  595. ...
  596. -----END PGP PUBLIC KEY BLOCK-----
  597. W:
  598. W: --6b8b4567327b23c6643c986966334873--
  599. {::include ../shared/fence-line.mkd}
  600. ## Sending Side Considerations
  601. <!-- HB: preserved as commented out for the moment, as we may re-use part of this
  602. ### Stub Outer Header
  603. \[\[ TODO (AM): Consider merging this section with the following one.
  604. At the moment advice presented by these 2 sections is contradictory.
  605. \]\]
  606. The outer message requires a minimal set of header fields to be in
  607. place for being eligible for transport. This includes the "From",
  608. "To", "Cc", "Bcc", "Subject" and "Message-ID" header fields.
  609. Submission and forwarding based on SMTP carries "sender" and "receivers"
  610. information in SMTP transaction, outside of the message object,
  611. so that the "From" and "To" header fields are
  612. not strictly necessary. Nevertheless, "From", "Date", and at least one
  613. destination header field is mandatory as per {{RFC5322}}. They SHOULD
  614. be conserved for reliability.
  615. The following header fields should contain a verbatim copy of the
  616. header fields of the inner message:
  617. * Date
  618. * From
  619. * To
  620. * Cc (*)
  621. * Bcc (*)
  622. The entries with an asterisk mark (*) should only be set if also
  623. present in the original message.
  624. -->
  625. ### Candidate Header Fields for Header Protection {#candidate-header-fields}
  626. \[\[ TODO: This section is very early stage and needs more work. \]\]
  627. <!-- Preserved as comment:
  628. By default, all header fields of the original message SHOULD be
  629. wrapped with the original message, with one exception:
  630. * the header field "Bcc" MUST NOT be added to the protected headers.
  631. -->
  632. For a 'signature only' (cf. {{protection-levels}}) message, it is
  633. RECOMMENDED that all "outer" header fields are identical to the
  634. "inner" protected header fields. This would mean that all header
  635. fields are signed. In this case, the "outer" header fields simply
  636. match the protected header fields. And in the case that the "outer"
  637. header fields differ, they can simply be replaced with their protected
  638. versions when displayed to the user.
  639. \[\[ TODO: Decide whether "Bcc" header field should be excluded.
  640. Also verify whether this requirement applies generally or
  641. just for specific implementations. \]\]
  642. When generating S/MIME messages with applied (signature and)
  643. encryption to protect header fields:
  644. 1. If a header field is being encrypted because it is sensitive, its
  645. true value MUST NOT be included in the outer header. If the
  646. header field is mandatory according to {{RFC5322}}, a stub value (or
  647. a value indicating that the outer value is not to be used) is to
  648. be included in the outer header section.
  649. 2. The outer header section SHOULD be minimal in order to avoid
  650. disclosure of confidential information. It is recommended that
  651. the outer header section only contains "Date" (set to the same
  652. value as in the inner header field, or, if the Date value is also
  653. sensitive, to Monday 9am of the same week), possibly "Subject"
  654. and "To"/"Cc" header fields. ("From", "Date", and at least one
  655. destination header field is mandatory as per {{RFC5322}}.)
  656. In particular, Keywords, In-Reply-To and References header fields
  657. SHOULD NOT be included in the outer header; "To" and "Cc" header
  658. fields should be omitted and replaced with "Bcc: undisclosed-recipients;".
  659. But note that having key header fields duplicated in the outer
  660. header is convenient for many message stores (e.g. IMAP) and
  661. clients that can't decode S/MIME encrypted messages. In
  662. particular, Subject/To/Cc/Bcc/Date header field values are
  663. returned in IMAP ENVELOPE FETCH data item {{RFC3501}}, which is
  664. frequently used by IMAP clients in order to avoid parsing message
  665. header.
  666. 3. The "Subject" header field value of the outer header section
  667. SHOULD either be identical to the inner "Subject" header field
  668. value, or contain a clear indication that the outer value is not
  669. to be used for display (the inner header field value would
  670. contain the true value).
  671. Note that recommendations listed above typically only apply to non
  672. MIME header fields (header fields with names not starting with
  673. "Content-" prefix), but there are exceptions, e.g. Content-Language.
  674. Note that the above recommendations can also negatively affect
  675. anti-spam processing.
  676. Messages containing at least one recipient address in the Bcc
  677. header field may appear in up to three different variants:
  678. 1. The message for the recipient addresses listed in To or Cc
  679. header fields, which must not include the Bcc header field neither
  680. for signature calculation nor for encryption.
  681. 2. The message(s) sent to the recipient addresses in the Bcc header
  682. field, which depends on the implementation:
  683. a) One message for each recipient in the Bcc header field
  684. separately with a Bcc header field containing only the address
  685. of the recipient it is sent to
  686. b) The same message for each recipient in the Bcc header field with
  687. a Bcc header field containing an indication such as "Undisclosed
  688. recipients" (but no addressees)
  689. c) The same message for each recipient in the Bcc header field
  690. which does not include a Bcc header field (this message is
  691. identical to 1. / cf. above)
  692. 3. The message stored in the 'Sent'-Folder of the sender, which
  693. usually contains the Bcc unchanged from the original message,
  694. i.e. with all recipient addresses.
  695. <!-- old version kept
  696. 2. The message(s) sent to the recipient addresses in the Bcc header
  697. field, which depends on the implementation:
  698. a) One message for each recipient in the Bcc header field
  699. separately with a Bcc header field containing only the address
  700. of the recipient it is sent to.
  701. b) One message for each recipient in the Bcc header field
  702. separately without a Bcc header field or a Bcc header field
  703. containing an indication such as "Undisclosed recipients" (but
  704. no addressees).
  705. c) One message for all recipients in the Bcc header field without
  706. a Bcc header field or a Bcc header field containing an
  707. indication such as "Undisclosed recipients" (but no addresses).
  708. Note that this variant may have adverse side effects regarding
  709. privacy as recipients in the Bcc header field may see all
  710. recipient addresses listed in the Bcc header field.
  711. -->
  712. Regarding the Bcc header field there should be no difference between
  713. the inner and the outer header section.
  714. ## Receiving Side Considerations
  715. ### Which Header Fields to Display to User
  716. When displaying S/MIME messages which protect header fields
  717. (independent of which protection level 'signature and encryption',
  718. 'signature only' or 'encryption only' is applied to
  719. (cf. {{protection-levels}}):
  720. 1. The outer header fields might be tampered with, so a receiving client
  721. SHOULD ignore them, unless they are protected in some other
  722. way(\*). If a header field is present in the inner header, only
  723. the inner header field value MUST be displayed (and the
  724. corresponding outer value must be ignored). If a particular
  725. header field is only present in the outer header, it MAY be
  726. ignored (not displayed) or it MAY be displayed with a clear
  727. indicator that it is not trustworthy(*).
  728. (\*) - this only applies if the header field is not protected is
  729. some other way, for example with a DKIM signature that validates
  730. and is trusted.
  731. ### Mail User Agent Algorithm for deciding which version of a header field to display {#algorithm-hf-display}
  732. \[\[ TODO: describe how to recurse to find the innermost protected root
  733. body part, extract header fields from it and propagate them to the
  734. top level. This should also work for triple-wrapped messages.\]\]
  735. <!--
  736. \[\[ TODO (AM): Decide what to do this this. Does it go to another
  737. place in this document? Anything to Requirements? Will it be only part
  738. of the solution document? \]\]
  739. -->
  740. <!-- =========================================================================== -->
  741. # Document Changelog
  742. \[\[ RFC Editor: This section is to be removed before publication \]\]
  743. * draft-ietf-lamps-header-protection-requirements-00
  744. * Initial version
  745. * draft-ietf-lamps-header-protection-requirements-01
  746. * Moved Implementation Considerations to Appendix (HB)
  747. * Shortened abstract (HB)
  748. * Many editorial changes, e.g., replaced "content-type" with
  749. "Content-Type". (HB)
  750. * Added example for Option 2.1 / pEp (HB)
  751. * Added (short) definition of Header Protection (HB)
  752. * Added more information regarding Bcc (feedback IETF-105) (HB)
  753. * Simplified GS3 (HB)
  754. * Added GR3 (HB)
  755. # Open Issues
  756. \[\[ RFC Editor: This section should be empty and is to be removed
  757. before publication. \]\]
  758. * Enhance Introduction and Problem Statement sections
  759. * Decide in which form legacy HP requirements should remain in this
  760. document
  761. * Improve definitions in {{protection-levels}}
  762. * Should requirement G3 remain? If you consider improve / rewrite it.
  763. * Add more text on Memory Hole
  764. * Rephrase {{rfc822-wrapping}}
  765. * Resolve question regarding Bcc in
  766. {{candidate-header-fields}}
  767. * Rewrite {{candidate-header-fields}}
  768. * Write {{algorithm-hf-display}}
  769. * Correct terminology for Header(s) and Header Fields throughout the
  770. document (editorial).
  771. * Header: Whole Header Section of the message
  772. * Header Field: Part / single Line inside a Header (Section)
  773. * Replace "email" by "email message" as needed
  774. <!--
  775. LocalWords: utf docname toc sortrefs symrefs Oberer Graben uri Ucom
  776. LocalWords: Winterthur Hoeneisen GmbH Zuerich bernhard hoeneisen rfc
  777. LocalWords: ucom ietf melnikov birk trustwords keysync Volker ann cb
  778. LocalWords: ISOC bnet OpenPGP pgp msg asc pEpkey MUAs UI req SMTP WG
  779. LocalWords: UX Programme Changelog IMAP DKIM DMARC DomainKeys HB HFs
  780. LocalWords: implementer's pkcs SignedData cryptographically LF
  781. LocalWords: prio charset Bcc LSS LSR wrt DKG prepending TBD fc
  782. LocalWords: recurse TLS EFAIL cleartext plaintext mixnet MMHS
  783. LocalWords: anonymization Alexey Isode ascii prepended micalg
  784. LocalWords: sha cbe Chuang Kille cryptographic interoperability
  785. LocalWords: roadmap
  786. -->