Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Informational                              B. Hoeneisen
Expires: January 9, April 30, 2020                                          Ucom.ch
                                                           July 08,
                                                        October 28, 2019

        Problem Statement and Requirements for Header Protection
           draft-ietf-lamps-header-protection-requirements-00
           draft-ietf-lamps-header-protection-requirements-01

Abstract

   Privacy and security issues with email header protection in S/MIME
   have been identified for some time.  However, the desire to fix these
   issue
   issues has only recently been expressed in the IETF LAMPS Working Group only
   recently.
   Group.  The existing S/MIME specification is likely to be updated
   regarding header protection.

   Several LAMPS WG participants expressed the opinion that whatever
   mechanism will be chosen, it should not be limited to S/MIME, but
   also applicable to PGP/MIME.

   This document describes the problem statement, generic use cases, and
   requirements.  Additionally it drafts possible solutions to address
   the challenge.  Finally some best practices are collected.
   requirements of header protection.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 9, April 30, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Usability . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Interoperability  . . . . . . . . . . . . . . . . . . . .   5
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Interactions  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Protection Levels . . . . . . . . . . . . . . . . . . . .   6
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6   7
     4.1.  General Requirements  . . . . . . . . . . . . . . . . . .   6   7
       4.1.1.  Sending Side  . . . . . . . . . . . . . . . . . . . .   7
       4.1.2.  Receiving Side  . . . . . . . . . . . . . . . . . . .   7   8
     4.2.  Additional Requirements for Backward-Compatibility With
           Legacy Clients Unaware of Header Protection . . . . . . .   8
       4.2.1.  Sending side  . . . . . . . . . . . . . . . . . . . .   8
       4.2.2.  Receiving side  . . . . . . . . . . . . . . . . . . .   8   9
     4.3.  Additional Requirements for Backward-Compatibility with
           Legacy Header Protection Systems (if supported) . . . . .   8   9
       4.3.1.  Sending Side  . . . . . . . . . . . . . . . . . . . .   9
       4.3.2.  Receiving Side  . . . . . . . . . . . . . . . . . . .   9
   5.  Options to Achieve Header Protection  .  Security Considerations . . . . . . . . . . .   9
     5.1.  Option 1: Memory Hole . . . . . . . .   9
   6.  Privacy Considerations  . . . . . . . . . .   9
     5.2.  Option 2: Wrapping with message/rfc822 or message/global    9
       5.2.1.  Content-Type Parameter "forwarded" . . . . . . . . .  10
     5.3.  Option 2.1: Progressive Header Disclosure
   7.  IANA Considerations . . . . . . . .  10
     5.4.  Examples . . . . . . . . . . . . .  10
   8.  Acknowledgments . . . . . . . . . . .  11
       5.4.1.  Option 1: Memory Hole . . . . . . . . . . . .  10
   9.  References  . . . .  12
       5.4.2.  Option 2: Wrapping with message/rfc822 or
               message/global . . . . . . . . . . . . . . . . . . .  13
       5.4.3.  Option 2.1 Progressive Header Disclosure . .  10
     9.1.  Normative References  . . . .  14
   6.  Sending Side Considerations . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . .  14
     6.1.  Candidate Header Fields for Header Protection . . . . . .  14
   7.  Receiving Side Considerations . . . . . . . .  11
   Appendix A.  Implementation Considerations  . . . . . . . .  16
     7.1.  Which Header Fields to Display to User . . . . . . . . .  16
     7.2.  Mail User Agent Algorithm for deciding which version of a
           header field  12
     A.1.  Options to display . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . Achieve Header Protection  . .  16
   9.  Privacy Considerations . . . . . . . .  12
       A.1.1.  Option 1: Memory Hole . . . . . . . . . . .  17
   10. IANA Considerations . . . . .  12
       A.1.2.  Option 2: Wrapping with message/rfc822 or
               message/global  . . . . . . . . . . . . . . . .  17
   11. Acknowledgments . . .  12
       A.1.3.  Option 2.1: Progressive Header Disclosure . . . . . .  13
       A.1.4.  Examples  . . . . . . . . . . . . . .  17
   12. References . . . . . . . .  14
     A.2.  Sending Side Considerations . . . . . . . . . . . . . . .  20
       A.2.1.  Candidate Header Fields for Header Protection . .  17
     12.1.  Normative References . .  20
     A.3.  Receiving Side Considerations . . . . . . . . . . . . . .  21
       A.3.1.  Which Header Fields to Display to User  . .  17
     12.2.  Informative References . . . . .  22
       A.3.2.  Mail User Agent Algorithm for deciding which version
               of a header field to display  . . . . . . . . . . . .  18  22
   Appendix A. B.  Document Changelog . . . . . . . . . . . . . . . . .  18  22
   Appendix B. C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  19  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  23

1.  Introduction

   [[ Note: Please be advised that this document is early work-in-
   progress, and will substantially change in future revisions. ]]

   A range of protocols for the protection of electronic mail (email)
   exist, which allow to assess the authenticity and integrity of the
   email headers section or selected header fields (HF) from the domain-level domain-
   level perspective, specifically DomainKeys Identified Mail (DKIM)
   [RFC6376] and Sender Policy Framework (SPF) [RFC7208] [RFC7208], and Domain-based Domain-
   based Message Authentication, Reporting, and Conformance (DMARC)
   [RFC7489].  These protocols, while essential to responding to a range
   of attacks on email, do not offer full end-to-end protection to the headers
   header section and are not capable of providing privacy for the
   information contained therein.

   The need for means of Data Minimization, which includes data
   spareness and the hiding of all technically concealable information whenever
   possible, has grown in importance over the past several years.

   A standard for end-to-end protection of the email headers header section
   exists for S/MIME since version 3.1. 3.1 and later. (cf.  [RFC8551]):

      In order to protect outer, non-content-related message header
      fields (for instance, the "Subject", "To", "From", and "Cc"
      fields), the sending client MAY wrap a full MIME message in a
      message/rfc822 wrapper in order to apply S/MIME security services
      to these header fields.

   No mechanism for header protection (HP) has been standardized for PGP
   (Pretty Good Privacy) [RFC4880] yet.

   End-to-end protection

   Several varying implementations of end-to-end protections for the email headers section is currently not
   widely implemented - neither for messages protected by means of
   S/MIME nor PGP.  At least two variants of
   header protection are known sections exist, though the total number of such
   implementations appears to be implemented. rather low.

   Some LAMPS WG participants expressed the opinion that whatever
   mechanism will be chosen, it should not be limited to S/MIME, but
   also applicable to PGP/MIME.

   This document describes the problem statement, statement (Section 2), generic
   use cases (Section 3) and requirements for header protection Header Protection
   (Section 4).
   Additionally it drafts  In Appendix A, possible solutions to address the challenge.
   However,
   challenge and some best practices are collected.  In any case, the
   final solution will is to be determined by the IETF LAMPS WG.
   Finally, some best practices are collected.

   [[ TODO: enhance this section ]]

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terms

   The following terms are defined for the scope of this document:

   o  Header Field:: cf. [RFC5322]

   o Protection (HP): cryptographic protection of email Header Section: cf. [RFC5322]

   o  Signed-only message: a multipart/signed or application/pkcs7-mime
      containing SignedData message which doesn't contain any encrypted
      layer.  I.e. this is a message which is not encrypted
      Sections for signatures and not
      encrypted + signed. encryption

   o  Header Field (HF): cf. [RFC5322]

   o  Header Section (HS): cf. [RFC5322]

   o  Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
      form of active wiretapping attack in which the attacker intercepts
      and selectively modifies communicated data to masquerade as one or
      more of the entities involved in a communication association."

   o  'Signature and encryption', 'signature only' or 'encryption only'
      are further explained in Section 3.2.

2.  Problem Statement

   The LAMPS charter contains the following Work Item:

      Update the specification for the cryptographic protection of email
      headers - both for signatures and encryption - to improve the
      implementation situation with respect to privacy, security,
      usability and interoperability in cryptographically-protected
      electronic mail.  Most current implementations of
      cryptographically-protected electronic mail protect only the body
      of the message, which leaves significant room for attacks against
      otherwise-protected messages.

   In the following a set of challenges to be addressed:

   [[ TODO: enhance this section section, add more items to the following ]]

2.1.  Privacy

   o  Data Minimization, which includes data spareness and hiding all
      technically concealable information whenever possible

2.2.  Security

   o  MITM attacks (cf.  [RFC4949])

2.3.  Usability

   o  User interaction / User experience

2.4.  Interoperability

   o  Interoperability with [RFC8551] implementations

3.  Use Cases

   In the following, we show following a list of the generic use cases that need to be
   addressed for messages with Header Protection (HP).  These use cases
   apply independently of whether S/MIME, PGP/MIME or any other
   technology is used for which Header Protection (HP) is to be applied
   to. achieve HP.

3.1.  Interactions

   The main interaction case for Header Protection (HP) is:

   1) Both peers (sending and receiving side) fully support HP

   For backward compatibility of legacy clients - unaware of any HP -
   the following intermediate interactions need to be considered as
   well:

   2) The sending side fully supports HP, while the receiving side does
      not support any HP

   3) The sending side does not support any HP, while the receiving
      side fully supports HP (trivial case)

   4) Neither the sending side nor the receiving side supports any HP
      (trivial case)

   The following intermediate use cases may need to be considered as
   well for backward compatibility with legacy HP systems, such as
   S/MIME since version 3.1 and later (cf.  [RFC8551]), in the following
   designated as legacy HP:

   5) The sending side fully supports HP, while the receiving side
      supports legacy HP only

   6) The sending side supports legacy HP only, while the receiving side
      fully supports HP

   7) Both peers (sending and receiving side) support legacy HP only

   8) The sending side supports legacy HP only, while the receiving side
      does not support any HP

   9) The sending side does not support any HP, while the receiving side
      supports legacy HP only (trivial case)

   Note: It is to be decided whether to ensure legacy HP systems do not
   conflict with any new solution for HP at all or whether (and to which
   degree) backward compatibility to legacy HP systems shall be
   maintained.

   [[ TODO: Decide in which form legacy HP requirements should remain in
   this document. ]]

3.2.  Protection Levels

   The following protection levels need to be considered:

   a) signature Signature and encryption

   b)

   Messages containing a cryptographic signature which are also
   encrypted.

   Sending and receiving side SHOULD implement 'signature and
   encryption', which is the default to use on the sending side.

   b) Signature only

   c)

   Messages containing a cryptographic signature, but which no
   encryption is applied to.

   Certain implementations MAY decide to send 'signature only' messages,
   depending on the circumstances and customer requirements.  Sending
   and Receiving sides SHOULD implement 'signature only'.

   c) Encryption only [[ TODO: verify whether relevant ]]

   Messages that encryption is applied to which do not contain a
   cryptographic signature.

   'Encryption only' is NOT RECOMMENDED on the sending side, however the
   receiving side needs certain guidelines on how to process received
   'encrypted only' messages

4.  Requirements

   In the

   The following is a list of requirements that need to be addressed
   independently of whether S/MIME, PGP/MIME or any other technology is
   used to apply HP to.

4.1.  General Requirements

   Note: This subsection is listing lists the requirements to address use case 1)
   (cf.  Section 3.1).

  G1: Define the format for HP format for all protection levels (cf. above), which
      includes MIME structure, Content-Type (including all parameters,
      such as "charset" and "name"), Content-Disposition (including all
      parameters, such as "filename"), and Content-Transfer-Encoding.

  G2: To foster wide implementation of the new solution, it shall be
      easily implementable. Unless needed for maximizing protection and
      privacy, existing implementations shall not require substantial
      changes in the existing code base. In particular also MIME
      libraries widely used shall not need to be changed to comply with
      the new mechanism for HP.

  G3: There SHOULD be only one a single format that covers all Protection Levels protection levels
      (cf. {{protection-levels}})) above).

      [[ TODO: Should this one remain in the document?
          If yes, consider improve / rewrite sentence
       ]] document?]]

  G4: Ensure that man-in-the-middle attack (MITM) (MITM, cf. {{RFC4949}}, [RFC4949]), in
      particular downgrade attacks, are mitigated as good as to the greatest extent
      possible.

4.1.1.  Sending Side
   GS1: Determine which Header Fields (HFs) should or must be protected
        at least
        for signed only email. 'signature only' emails at a minimum.

   GS2: Determine which HFs should or must be sent in clear of an
        encrypted email. text (i.e.,
        included in the outer header) for emails with (signature and)
        encryption applied.

   GS3: Determine which HF HFs should not or must not be sent in clear text
        (i.e., not be included in the
        visible header (for transport) outer header) of an encrypted email, email with the
        default being that whatever is not needed from GS2 is not put
        into the unencrypted transport headers, thus fulfilling data
        minimization requirements (including data spareness and hiding
        of all information that technically can be hidden).
        (signature and) encryption applied.

   GS4: Determine which HF HFs to not to include to any HP part (e.g. Bcc).

4.1.2.  Receiving Side

   GR1: Determine how HF HFs should be displayed to the user in case of
        conflicting information between the protected and unprotected
        headers.
        HFs.

   GR2: Ensure that man-in-the-middle attack (MITM) attacks (MITM, cf. {{RFC4949}}, [RFC4949]), in
        particular downgrade attacks, can be detected.

   GR3: Define how emails that 'encryption only' was applied to
        are to be treated.

4.2.  Additional Requirements for Backward-Compatibility With Legacy
      Clients Unaware of Header Protection

   Note: This sub-section addresses the use cases 2) - 4) (cf.
   Section 3.1)

   B1: Depending on the solution, define Define a means to distinguish between forwarded messages emails and
       encapsulated messages emails using new HP mechanism.

4.2.1.  Sending side

   BS1: Define how full HP support can be indicated to outgoing
        messages.
        emails.

   BS2: Define how full HP support of the receiver can be detected or
        guessed.
        derived.

   BS3: Ensure a HP unaware HP-unaware receiving side easily can display the
        "Subject" HF to the user.

4.2.2.  Receiving side

   BR1: Define how full HP support can be detected in incoming messages. emails.

4.3.  Additional Requirements for Backward-Compatibility with Legacy
      Header Protection Systems (if supported)

   Note: This sub-section addresses the use cases 5) - 9) (cf.
   Section 3.1).

   LS1: Depending on the solution, define a means to distinguish between
        forwarded messages, emails, legacy encapsulated messages, emails, and
        encapsulated messages emails using new HP mechanism.

   LS2: The solution should be backward compatible to existing solutions
        and aim to minimize the implementation effort to include support
        for existing solutions.

4.3.1.  Sending Side

   LSS1: Determine how legacy HP support can be indicated to outgoing
         messages.
         emails.

   LSS2: Determine how legacy HP support of the receiver can be detected
         or guessed. derived.

4.3.2.  Receiving Side

   LSR1: Determine how legacy HP support can be detected in incoming
         messages.
         emails.

5.  Options to Achieve  Security Considerations

   This document talks about UI considerations, including security
   considerations, when processing messages protecting Header Protection

   In Fields.
   One of the following a set goals of Options this document is to achieve Email Header Protection.
   It specify UI for displaying
   such messages which is expected that less confusing/misleading for the IETF LAMPS WG chooses an option to update
   [RFC8551] wrt.  Header Protection.

5.1.  Option 1: Memory Hole

   Memory Hole approach works end-user and
   thus more secure.

   The document does not define a new protocol, and thus does not create
   any new security concerns not already covered by copying S/MIME [RFC8551],
   MIME [RFC2045] and Email [RFC5322] in general.

6.  Privacy Considerations

   [[ TODO ]]

7.  IANA Considerations

   This document requests no action from IANA.

   [[ RFC Editor: This section may be removed before publication. ]]

8.  Acknowledgments

   The authors would like to thank the normal message header
   fields following people who have
   provided helpful comments and suggestions for this document: David
   Wilson, Kelly Bristol, Robert Williams, Steve Kille, and Wei Chuang.

   Essential parts of [I-D.luck-lamps-pep-header-protection] have been
   merged into the MIME header this document.  Special thanks to its author Claudio
   Luck.  For further Acknowledgments, please refer to Acknowledgments
   section of [I-D.luck-lamps-pep-header-protection].

   David Wilson came up with the idea of defining a new Content-Type
   header field parameter to distinguish forwarded messages from inner
   header field protection constructs.

9.  References

9.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

9.2.  Informative References

   [I-D.luck-lamps-pep-header-protection]
              Luck, C., "pretty Easy privacy (pEp): Progressive Header
              Disclosure", draft-luck-lamps-pep-header-protection-03
              (work in progress), July 2019.

   [I-D.marques-pep-email]
              Marques, H., "pretty Easy privacy (pEp): Email Formats and
              Protocols", draft-marques-pep-email-02 (work in progress),
              October 2018.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880,
              DOI 10.17487/RFC4880, November 2007,
              <https://www.rfc-editor.org/info/rfc4880>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

Appendix A.  Implementation Considerations

   [[ Note: Please be advised that this part of the document is early
   work-in-progress. ]]

   This Appendix A contains additional information and considerations
   regarding the implementation.  Although not (strictly) part of the
   requirements, this is useful to better understand them.  Parts of the
   text in this Appendix A will likely be moved to the upcoming
   implementation document.

A.1.  Options to Achieve Header Protection

   The following are current options for addressing Email Header
   Protection.  The IETF LAMPS WG may choose from these options in order
   to update [RFC8551].

A.1.1.  Option 1: Memory Hole

   The Memory Hole approach works by copying the normal message header
   fields into the MIME header section of the top level protected body
   part.  Since the MIME body part header section is itself covered by
   the protection mechanisms (signing (signature and/or encryption) it shares the
   protections of the message body.

   [[ TODO: add more information on memory hole ]]

5.2.

A.1.2.  Option 2: Wrapping with message/rfc822 or message/global

   Wrapping with message/rfc822 (or message/global) works by copying the
   normal message header fields into the MIME header section of the top
   level protect body part

   [[ TODO: consider rephrasing, as not only the header fields is
   copied, but also the content.]]

   and then prepending them with "Content-Type: message/rfc822;
   forwarded=no\r\n" or "Content-Type: message/global;
   forwarded=no\r\n", where \r\n is US-ASCII CR followed by US-ASCII LF. LF
   (see also Appendix A.1.2.1).  Since the MIME body part header section
   is itself covered by the protection mechanisms (signing (signature and/or
   encryption) it shares the protections of the message body.

5.2.1.

A.1.2.1.  Content-Type Parameter "forwarded"

   This section outlines how the new "forwarded" Content-Type header
   field parameter could be defined (probably in a separate document)
   and how header section wrapping works:

   This document defines a new Content-Type header field parameter
   [RFC2045] with name "forwarded".  The parameter value is case-
   insensitive and can be either "yes" or "no".  (The default value
   being "yes").  The parameter is only meaningful with media type
   "message/rfc822" and "message/global" [RFC6532] when used within
   S/MIME or PGP/MIME signed or encrypted body parts.  The value "yes"
   means that the message nested inside "message/rfc822" ("message/global") ("message/
   global") is a forwarded message and not a construct created solely to
   protect the inner header section.

   Instructions in [RFC8551] describing how to protect the Email message
   header section [RFC5322], by wrapping the message inside a message/
   rfc822 container [RFC2045] are thus updated to read:

      In order to protect outer, non-content-related message header
      fields (for instance, the "Subject", "To", "From", and "Cc"
      fields), the sending client MAY wrap a full MIME message in a
      message/rfc822 wrapper in order to apply S/MIME security services
      to these header fields.  It is up to the receiving client to
      decide how to present this "inner" header section along with the
      unprotected "outer" header section.

      When an S/MIME message is received, if the top-level protected
      MIME entity has a Content-Type of message/rfc822 or message/global
      without the "forwarded" parameter or with the "forwarded"
      parameter set to "no", it can be assumed that the intent was to
      provide header protection.  This entity SHOULD be presented as the
      top-level message, taking into account header section merging
      issues as previously discussed.

5.3.

A.1.3.  Option 2.1: Progressive Header Disclosure

   This option is similar to Option 2 (cf.  Section 5.2).  Appendix A.1.2).  It also
   makes use the Content-Type parameter "forwarded" (cf.  Section 5.2.1).
   Appendix A.1.2.1).

   pEp for email [I-D.marques-pep-email] defines a fixed MIME structure
   for its innermost message structure.  Security comes just next after
   privacy in pEp, for which reason the application of signatures
   without encryption to messages in transit is not considered
   purposeful. pEp for email, either expects to transfer messages in
   cleartext without signature or encryption, or transfer them encrypted
   and with enclosed signature and necessary public keys so that replies
   can be immediately upgraded to encrypted messages.

   The pEp message format is equivalent to the S/MIME standard in
   ensuring header protection, in that the whole message is protected
   instead, by wrapping it and providing cryptographic services to the
   whole original message.  However, for the purpose of allowing the
   insertion of public keys, the root entity of the protected message is
   thus nested once more into an additional multipart/mixed MIME entity.
   The current pEp proposal is for PGP/MIME, while an extension to
   S/MIME is also on the roadmap.

   pEp has also implemented the above (in Section 5.2.1) Appendix A.1.2.1) described
   Content-Type parameter "forwarded" to distinguish between
   encapsulated and forwarded emails.

   More information on progressive header disclosure can be found in
   [I-D.luck-lamps-pep-header-protection].

5.4.

A.1.4.  Examples

   Examples in subsequent sections assume that an email client is trying
   to protect (sign) the following initial message:

  Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  From: "Alexey Melnikov" <alexey.melnikov@example.net>
  Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  MIME-Version: 1.0
  MMHS-Primary-Precedence: 3
  Subject: Meeting at my place
  To: somebody@example.net
  X-Mailer: Isode Harrier Web Server
  Content-Type: text/plain; charset=us-ascii

  This is an important message that I don't want to be modified.

     Without message header protection the corresponding signed message
     might look like this.  (Lines prepended by "O: " are the outer
     header.)

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  O: Subject: Meeting at my place
  O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  O: MIME-Version: 1.0
  O: content-type: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  O:  protocol="application/pkcs7-signature";
  O:  boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

     This is a multipart message in MIME format.
     --.cbe16d2a-e1a3-4220-b821-38348fc97237
     Content-Type: text/plain; charset=us-ascii

     This is an important message that I don't want to be modified.

     --.cbe16d2a-e1a3-4220-b821-38348fc97237
     Content-Transfer-Encoding: base64
     content-type:
     Content-Type: application/pkcs7-signature

     [[base-64 encoded signature]]

     --.cbe16d2a-e1a3-4220-b821-38348fc97237--

5.4.1.

A.1.4.1.  Option 1: Memory Hole

   The following example demonstrates how header section and payload of
   a protect body part might look like.  For example, this will be the
   first body part of a multipart/signed message or the signed and/or
   encrypted payload of the application/pkcs7-mime body part.  Lines
   prepended by "O: " are the outer header section.  Lines prepended by
   "I: " are the inner header section.

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  O: Subject: Meeting at my place
  O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  O: MIME-Version: 1.0
  O: content-type: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  O:  protocol="application/pkcs7-signature";
  O:  boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

     This is a multipart message in MIME format.
     --.cbe16d2a-e1a3-4220-b821-38348fc97237
  I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  I: MIME-Version: 1.0
  I: MMHS-Primary-Precedence: 3
  I: Subject: Meeting at my place
  I: To: somebody@example.net
  I: X-Mailer: Isode Harrier Web Server
  I: Content-Type: text/plain; charset=us-ascii

     This is an important message that I don't want to be modified.

     --.cbe16d2a-e1a3-4220-b821-38348fc97237
     Content-Transfer-Encoding: base64
     content-type:
     Content-Type: application/pkcs7-signature

     [[base-64 encoded signature]]

     --.cbe16d2a-e1a3-4220-b821-38348fc97237--

5.4.2.

   [[ TODO (AM): HB: Not sure whether the Outer Subject HF is replaced
   by "Encrypted Message" (or alike).  Please verify. ]]

A.1.4.2.  Option 2: Wrapping with message/rfc822 or message/global

   The following example demonstrates how header section and payload of
   a protect body part might look like.  For example, this will be the
   first body part of a multipart/signed message or the signed and/or
   encrypted payload of the application/pkcs7-mime body part.  Lines
   prepended by "O: " are the outer header section.  Lines prepended by
   "I: " are the inner header section.  Lines prepended by "W: " are the
   wrapper.

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  O: Subject: Meeting at my place
  O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  O: MIME-Version: 1.0
  O: content-type: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  O:  protocol="application/pkcs7-signature";
  O:  boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

     This is a multipart message in MIME format.
     --.cbe16d2a-e1a3-4220-b821-38348fc97237
  W: Content-Type: message/rfc822; forwarded=no forwarded=no
  W:
  I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  I: MIME-Version: 1.0
  I: MMHS-Primary-Precedence: 3
  I: Subject: Meeting at my place
  I: To: somebody@example.net
  I: X-Mailer: Isode Harrier Web Server
  I: Content-Type: text/plain; charset=us-ascii

     This is an important message that I don't want to be modified.

     --.cbe16d2a-e1a3-4220-b821-38348fc97237
     Content-Transfer-Encoding: base64
     Content-Type: application/pkcs7-signature

     [[base-64 encoded signature]]

     --.cbe16d2a-e1a3-4220-b821-38348fc97237--

A.1.4.3.  Option 2.1 Progressive Header Disclosure

   The following example demonstrates how header section and payload of
   a protect body part might look like.  For example, this will be the
   first body part of a multipart/signed message or the signed and
   encrypted payload of the application/pkcs7-mime body part.  Lines
   prepended by "O: " are the outer header section.  Lines prepended by
   "I: " are the inner header section.  Lines prepended by "W: " are the
   wrapper.

   The main difference compared to Option 2 is an additional multipart/
   mixed Content-Type containing the original message (as a whole) and
   the public key (of the sender).

   Note: This example is derived from the pEp's PGP/MIME implementation
   and adjusted to the above S/MIME examples.  The pEp implementations
   do not support S/MIME yet; therefore the following can serve no more
   as for illustrative purpose.  Specific examples can be found in
   [I-D.luck-lamps-pep-header-protection].

  O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  O: Subject: Meeting at my place
  O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  W: MIME-Version: 1.0
  W: Content-Type: multipart/mixed;
  W:               boundary="6b8b4567327b23c6643c986966334873"
  W:
  W: --6b8b4567327b23c6643c986966334873
  W: Content-Type: message/rfc822; forwarded="no"
  W:
  I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
  I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
  I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
  I: MIME-Version: 1.0
  I: MMHS-Primary-Precedence: 3
  I: Subject: Meeting at my place
  I: To: somebody@example.net From: "Alexey Melnikov" <alexey.melnikov@example.net>
  I: X-Mailer: Isode Harrier Web Server MIME-Version: 1.0
  I: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
  I:  protocol="application/pkcs7-signature";
  I:  boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237

     This is a multipart message in MIME format.
     --.cbe16d2a-e1a3-4220-b821-38348fc97237
     Content-Type: text/plain; charset=us-ascii

     This is an important message that I don't want to be modified.

     --.cbe16d2a-e1a3-4220-b821-38348fc97237
     Content-Transfer-Encoding: base64
     content-type:
     Content-Type: application/pkcs7-signature

     [[base-64 encoded signature]]

     --.cbe16d2a-e1a3-4220-b821-38348fc97237--

5.4.3.  Option 2.1 Progressive Header Disclosure

   This looks similar as in option 2.  Specific examples can be found in
   [I-D.luck-lamps-pep-header-protection].

   [[ TODO: include an example of the same style. ]]

6.
  W: --6b8b4567327b23c6643c986966334873
  W: Content-Type: application/pgp-keys
  W: Content-Disposition: attachment; filename="pEpkey.asc"
  W:
     -----BEGIN PGP PUBLIC KEY BLOCK-----
     ...
     -----END PGP PUBLIC KEY BLOCK-----
  W:
  W: --6b8b4567327b23c6643c986966334873--

A.2.  Sending Side Considerations

6.1.

A.2.1.  Candidate Header Fields for Header Protection

   [[ TODO: This section is very early stage and needs more work. ]]

   For a signed-only 'signature only' (cf.  Section 3.2) message, it is RECOMMENDED
   that all "outer" header fields are identical to the "inner" protected
   header fields.  This would mean that all header fields are signed.
   In this case, the "outer" header fields simply match the protected
   header fields.  And in the case that the "outer" header fields
   differ, they can simply be replaced with their protected versions
   when displayed to the user.

   [[ TODO: Decide whether "Bcc" header field should be excluded.  Also
   verify whether this requirement applies generally or just for
   specific implementations. ]]

   When generating encrypted or encrypted+signed S/MIME messages which with applied (signature and)
   encryption to protect header fields:

   1.  If a header field is being encrypted because it is sensitive, its
       true value MUST NOT be included in the outer header.  If the
       header field is mandatory according to [RFC5322], a stub value
       (or a value indicating that the outer value is not to be used) is
       to be included in the outer header section.

   2.  The outer header section SHOULD be minimal in order to avoid
       disclosure of confidential information.  It is recommended that
       the outer header section only contains "Date" (set to the same
       value as in the inner header field, or, if the Date value is also
       sensitive, to Monday 9am of the same week), possibly "Subject"
       and "To"/"Bcc" "To"/"Cc" header fields.  ("From", "Date", and at least one
       destination header field is mandatory as per [RFC5322].)  In
       particular, Keywords, In-Reply-To and References header fields
       SHOULD NOT be included in the outer header; "To" and "Cc" header
       fields should be omitted and replaced with "Bcc: undisclosed-
       recipients;".

       But note that having key header fields duplicated in the outer
       header is convenient for many message stores (e.g.  IMAP) and
       clients that can't decode S/MIME encrypted messages.  In
       particular, Subject/To/Cc/Bcc/Date header field values are
       returned in IMAP ENVELOPE FETCH data item [RFC3501], which is
       frequently used by IMAP clients in order to avoid parsing message
       header.

   3.  The "Subject" header field value of the outer header section
       SHOULD either be identical to the inner "Subject" header field
       value, or contain a clear indication that the outer value is not
       to be used for display (the inner header field value would
       contain the true value).

   Note that recommendations listed above typically only apply to non
   MIME header fields (header fields with names not starting with
   "Content-" prefix), but there are exception, exceptions, e.g.  Content-Language.

   Note that the above recommendations can also negatively affect anti-
   spam processing.

7.  Receiving Side Considerations

7.1.  Which Header Fields to Display to User

   When displaying S/MIME messages which protect header fields (whether
   they are signed-only, encrypted or encrypted+signed):

   1.  The outer header fields might be tampered with, so a receiving
       client SHOULD ignore them, unless they are protected in some
       other way(_).  If a header field is present

   Messages containing at least one recipient address in the inner header,
       only the inner header field value MUST be displayed (and the
       corresponding outer value must be ignored).  If a particular Bcc header
   field is only present may appear in up to three different variants:

   1.  The message for the outer header, it MAY be
       ignored (not displayed) recipient addresses listed in To or it MAY be displayed with a clear
       indicator that it is Cc header
       fields, which must not trustworthy(_).

       (*) - this only applies if include the Bcc header field is not protected is
       some other way, neither for example with a DKIM
       signature that validates
       and is trusted.

7.2.  Mail User Agent Algorithm for deciding which version of a header
      field to display

   [[ TODO: describe how to recurse calculation nor for encryption.

   2.  The message(s) sent to find the innermost protected root
   body part, extract recipient addresses in the Bcc header fields from it and propagate them to
       field, which depends on the
   top level.  This should also work implementation:

       a) One message for triple-wrapped messages.]]

8.  Security Considerations

   This document talks about UI considerations, including security
   considerations, when processing messages protecting each recipient in the Bcc header fields.
   One of field
       separately with a Bcc header field containing only the goals address of this document
       the recipient it is sent to specify UI

       b) The same message for displaying each recipient in the Bcc header field
       with a Bcc header field containing an indication such messages as
       "Undisclosed recipients" (but no addressees)

       c) The same message for each recipient in the Bcc header field
       which does not include a Bcc header field (this message is less confusing/misleading and thus more
   secure.
       identical to 1. / cf. above)

   3.  The document is not defining new protocol, so it doesn't create any
   new security concerns not already covered by S/MIME [RFC8551], MIME
   [RFC2045] and Email [RFC5322] message stored in general.

9.  Privacy Considerations

   [[ TODO ]]

10.  IANA Considerations

   This document requests no action from IANA.

   [[ RFC Editor: This section may be removed before publication. ]]

11.  Acknowledgments

   The authors would like to thank the following people who have
   provided helpful comments and suggestions for this document: David
   Wilson, Steve Kille, Wei Chuang, and Robert Williams

   Essential parts of [I-D.luck-lamps-pep-header-protection] have been
   merged into this document.  Special thanks to its author Claudio
   Luck.  For further Acknowledgments, please refer to Acknowledgments
   section 'Sent'-Folder of [I-D.luck-lamps-pep-header-protection].

   David Wilson came up the sender, which
       usually contains the Bcc unchanged from the original message,
       i.e. with all recipient addresses.

   Regarding the Bcc header field there should be no difference between
   the inner and the idea of defining a new Content-Type outer header field parameter section.

A.3.  Receiving Side Considerations
A.3.1.  Which Header Fields to distinguish forwarded Display to User

   When displaying S/MIME messages from inner which protect header field fields
   (independent of which protection constructs.

12.  References

12.1.  Normative References

   [RFC2045]  Freed, N. level 'signature and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs encryption',
   'signature only' or 'encryption only' is applied to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

12.2.  Informative References

   [I-D.luck-lamps-pep-header-protection]
              Luck, C., "pretty Easy privacy (pEp): Progressive Header
              Disclosure", draft-luck-lamps-pep-header-protection-03
              (work (cf.
   Section 3.2):

   1.  The outer header fields might be tampered with, so a receiving
       client SHOULD ignore them, unless they are protected in progress), July 2019.

   [I-D.marques-pep-email]
              Marques, H., "pretty Easy privacy (pEp): Email Formats and
              Protocols", draft-marques-pep-email-02 (work some
       other way(*).  If a header field is present in progress),
              October 2018.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., the inner header,
       only the inner header field value MUST be displayed (and the
       corresponding outer value must be ignored).  If a particular
       header field is only present in the outer header, it MAY be
       ignored (not displayed) or it MAY be displayed with a clear
       indicator that it is not trustworthy(*).

       (*) - this only applies if the header field is not protected is
       some other way, for example with a DKIM signature that validates
       and M. Kucherawy, Ed.,
              "DomainKeys Identified is trusted.

A.3.2.  Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) User Agent Algorithm for
              Authorizing Use deciding which version of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, a header
        field to display

   [[ TODO: describe how to recurse to find the innermost protected root
   body part, extract header fields from it and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>. propagate them to the
   top level.  This should also work for triple-wrapped messages.]]

Appendix A. B.  Document Changelog

   [[ RFC Editor: This section is to be removed before publication ]]

   o  draft-ietf-lamps-header-protection-requirements-00

      *  Initial version

   o  draft-ietf-lamps-header-protection-requirements-01

      *  Moved Implementation Considerations to Appendix B. (HB)

      *  Shortened abstract (HB)

      *  Many editorial changes, e.g., replaced "content-type" with
         "Content-Type".  (HB)

      *  Added example for Option 2.1 / pEp (HB)

      *  Added (short) definition of Header Protection (HB)
      *  Added more information regarding Bcc (feedback IETF-105) (HB)

      *  Simplified GS3 (HB)

      *  Added GR3 (HB)

Appendix C.  Open Issues

   [[ RFC Editor: This section should be empty and is to be removed
   before publication. ]]

   o  Enhance Introduction and Problem Statement sections

   o  Decide in which form legacy HP requirements should remain in this
      document

   o  Signed-only protection needs further study

      *  pEp only does header protection by applying both signing and
         encryption.  Technically it is also possible to sign, but not
         encrypt the protected messages.  This needs further study.
         Feedback from IETF-104: Probably no need to specify it, but
         need to document the case.  Improve definitions in Section 3.2

   o  Should requirement G3 remain?  If you consider improve / rewrite
      it.

   o  Add more text on Memory Hole

   o  Rephrase Section 5.2

   o  Add example to Section 5.4.3 Appendix A.1.2

   o  Resolve question regarding Bcc in Section 6.1 Appendix A.2.1

   o  Rewrite Section 6.1 Appendix A.2.1

   o  Write Section 7.2 Appendix A.3.2

   o  Correct terminology for Header(s) and Header Fields throughout the
      document (editorial).

      *  Header: Whole Header Section of the message

      *  Header Field: Part / single Line inside a Header (Section)

   o  Replace "email" by "email message" as needed

Authors' Addresses
   Alexey Melnikov
   Isode Ltd
   14 Castle Mews
   Hampton, Middlesex  TW12 2NP
   UK

   Email: alexey.melnikov@isode.com

   Bernie Hoeneisen
   Ucom Standards Track Solutions GmbH
   CH-8046 Zuerich
   Switzerland

   Phone: +41 44 500 52 40
   Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
   URI:   https://ucom.ch/