internet-drafts/lamps-header-protection/draft-luck-lamps-pep-header-protection.mkd

---
coding: utf-8

title: "pretty Easy privacy (pEp): Progressive Header Disclosure"
abbrev: Progressive Header Disclosure 
docname:  draft-luck-lamps-pep-header-protection-04
category: info

stand_alone: yes
pi: [toc, sortrefs, symrefs, comments]

author:
{::include ../shared/author_tags/claudio_luck.mkd}
# {::include ../shared/author_tags/bernie_hoeneisen.mkd}

normative:
#  RFC822:
#  RFC1847:
#  RFC1341:
  RFC2046:
  PGPMIME: RFC3156
#  RFC3501:
  RFC4949:
  RFC5322:
#  RFC7435:
  RFC4880:
  RFC5490:
  RFC6376:
  RFC7208:
  RFC7489:
#  RFC8301:
#  RFC8463:
  RFC8551:
  I-D.melnikov-lamps-header-protection:
  I-D.birk-pep: 
  I-D.marques-pep-email:

informative:
#  RFC4880:
#  RFC5321:
#  RFC7258:
#  RFC7942:
#  I-D.marques-pep-handshake:
#  I-D.birk-pep-trustwords:
#  I-D.marques-pep-rating:
#  I-D.pep-keysync:
# {::include ../shared/references/isoc-btn.mkd}
{::include ../shared/references/implementation-status.mkd}


--- abstract

Issues with email header protection in S/MIME have been recently
raised in the IETF LAMPS Working Group. The need for amendments to the
existing specification regarding header protection was expressed.

The pretty Easy privacy (pEp) implementations currently use a mechanism quite
similar to the currently standardized message wrapping for S/MIME. The main
difference is that pEp is using PGP/MIME instead, and adds space for carrying
public keys next to the protected message.

In LAMPS, it has been expressed that whatever mechanism will
be chosen, it should not be limited to S/MIME, but also applicable to
PGP/MIME.

This document aims to contribute to this discussion and share the pEp
implementation experience with email header protection.

--- middle


# Introduction

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, but limited to a
domain-level perspective. Specifically these are DomainKeys
Identified Mail (DKIM) {{RFC6376}} and Sender Policy Framework (SPF)
{{RFC7208}} and 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 section and are not capable of
providing privacy regarding the information represented therein.

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

A standard for End-to-End protection of the email headers section
exists for S/MIME since version 3.1. (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 has been standardized for
{{PGPMIME}} yet.

End-to-End protection for the email headers section is currently not
widely implemented -- neither for messages protected by means of
S/MIME nor PGP/MIME. At least two variants of header protection are
known to be implemented. A recently submitted Internet-Draft
{{I-D.melnikov-lamps-header-protection}} discusses the two variants
and the challenges with header protection for S/MIME. The two
variants are referred to as:

* Option 1: Memory Hole
* Option 2: Wrapping with message/rfc822 or message/global

pEp (pretty Easy privacy) {{I-D.birk-pep}} for email
{{I-D.marques-pep-email}} already implements an option quite similar
to Option 2, adapting the S/MIME standards to PGP/MIME (cf.
{{message-format-for-progressive-header-disclosure}}, ff.). Existing
implementations of pEp have also added inbound support for "Memory
Hole" referred to above as Option 1, thus being able to study the
differences and the implementator's challenges.

pEp now also supports the "forwarded=no" attribute proposed in
{{I-D.melnikov-lamps-header-protection}}, and further described in
{{forwarded-no}}.

Interoperability and implementation symmetry between PGP/MIME and
S/MIME is planned by pEp, but still in an early stage of development.

This document describes Progressive Header Disclosure as implemented
in the "pEp message format version 2". This format inherently offers
header protection as a side effect, but is only intended for use only
with signed-and-encrypted messages. The feature of protecting
headers may be used independently by mail user agents otherwise not
wanting to conform to pEp standards
({{message-format-for-progressive-header-disclosure}}, ff.).


{::include ../shared/text-blocks/key-words-rfc2119.mkd}


{::include ../shared/text-blocks/terms-intro.mkd}

<!-- {::include ../shared/text-blocks/handshake.mkd} -->
<!-- {::include ../shared/text-blocks/trustwords.mkd} -->
<!-- {::include ../shared/text-blocks/tofu.mkd} -->
{::include ../shared/text-blocks/mitm.mkd}


# Message Format for Progressive Header Disclosure

## Compatibility

The pEp message format version 2 is designed such that a receiving Mail User
Agent (MUA), which is OpenPGP-compliant but not pEp-compliant, still has
built-in capability to properly verify the integrity of the mail, decode it
and display all information of the original mail to the user. The recovered
protected message is selfsufficiently described, including all protected
header fields.

The pEp message format version 2 (as used by all the various pEp
implementations, cf. {{implementation-status}}) is similar to what is
standardized for S/MIME in {{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.  It is up to the receiving client to decide how to present
>  this "inner" header along with the unprotected "outer" header.
> 
>  When an S/MIME message is received, if the top-level protected MIME
>  entity has a Content-Type of message/rfc822, it can be assumed that
>  the intent was to provide header protection.  This entity SHOULD be
>  presented as the top-level message, \[...\].

<!--
    NOTE: the first sentence in the quotation above is cited multiple times
    in this document.
-->


## Inner Message

**Note**: this section is for your information only. It does not add
requirements for the header protection feature to work.

The pEp message format requires the innermost protected message to follow a
fixed MIME structure and to consist of exactly one human-readable message which
is represented in plain or HTML format. Both plain and html entities MUST
represent the same message to the user. Any attachment to the message must be
laid out in a flat list. No additional multipart entities are allowed in the
pEp message.

These restrictions permit to build mail user agents which are immune to the
EFAIL attacks.

This message is herein further referred to as the "pEp inner message".

A mail user agent wanting to follow this standard, SHOULD transform any
"original message" into a "pEp inner message" for safe representation on the
receiving side.



## Content-Type Parameter "forwarded" {#forwarded-no}

One caveat of the design is that the user interaction with
message/rfc822 entities varies considerably across different mail
user agents. No standard is currently available which enables MUAs to
reliably determine whenever a nested message/rfc822 entity is meant
to blend the containing message, or if it was effectively intended to
be forwarded as a file document. pEp currently implements the
proposal described by {{I-D.melnikov-lamps-header-protection}}, 3.2,
which defines a new Content-Type header field parameter with name
"forwarded", for the MUA to distinguish between a forwarded message
and a nested message for the purpose of header protection, i.e.,
using "forwarded=no".


## Outer Message

With pEp message format version 2, the pEp standardized message is equally
wrapped in a message/rfc822 entity, but this time being in turn wrapped in a
multipart/mixed entity. The purpose of the additional nesting is to allow for
public keys of the sender to be stored alongside the original message while
being protected by the same mechanism.

For the case of PGP/MIME, the currently only implemented MIME encryption
protocol implemented in pEp, the top-level entity called the "outer
message" MUST contain:
 
 * exactly one entity of type message/rfc822, and
 * one or more entity of type application/pgp-keys

Notes on the current pEp client implementations:

 * the current pEp implementation also adds a text/plain entity containing
"pEp-Wrapped-Message-Info: OUTER" as first element in the MIME tree. This
element is not strictly necessary, but is in place for better backwards
compatibility when manually navigating the nested message structure. This is
part of the study of various solutions to maximize backwards compatibility,
and has been omitted from the following examples.

 * the current pEp implementation prepends "pEp-Wrapped-Message-Info:
INNER\<CR\>\<LF\>" to the original message body. This is an implementation
detail which should be ignored, and has been omitted in the following examples.

 * the current pEp implementation may render a text/plain directly in place of
the multipart/alternate, when no HTML representation was generated by the
sending MUA. This is not strict according to pEp's own specification, and is
currently being investigated.

<!--
Note that pEp clients MUST produce protected messages which have a flat MIME
tree. A pEp message MUST have exactly one multipart/alternative entity as its
first contained entity, eventually wrapped in a multipart/mixed entity to
append attachments following the multipart/alternative entity.
-->

This is an example of the top-level MIME entity, before being encrypted and 
signed:

~~~~
    MIME-Version: 1.0
    Content-Type: multipart/mixed;
                  boundary="6b8b4567327b23c6643c986966334873"


    --6b8b4567327b23c6643c986966334873
    Content-Type: message/rfc822; forwarded="no"

    From: John Doe <jdoe@machine.example>
    To: Mary Smith <mary@example.net>
    Subject: Example
    Date: Fri, 30 Jun 2018 09:55:06 +0200
    Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
    X-Pep-Version: 2.0
    MIME-Version: 1.0
    Content-Type: multipart/alternative;
                  boundary="29fe9d2b2d7f6a703c1bffc47c162a8c"

    --29fe9d2b2d7f6a703c1bffc47c162a8c
    Content-Type: text/plain; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: inline; filename="msg.txt"

    p=E2=89=A1p for Privacy by Default.
    -- =20
    Sent from my p=E2=89=A1p for Android.

    --29fe9d2b2d7f6a703c1bffc47c162a8c
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    p=E2=89=A1p for Privacy by Default.<br>
    -- <br>
    Sent from my p=E2=89=A1p for Android.<br>

    --29fe9d2b2d7f6a703c1bffc47c162a8c--
    --6b8b4567327b23c6643c986966334873
    Content-Type: application/pgp-keys
    Content-Disposition: attachment; filename="pEpkey.asc"

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    ...
    -----END PGP PUBLIC KEY BLOCK-----

    --6b8b4567327b23c6643c986966334873--
~~~~


## Transport Message

In pEp message format 2 the "outer message" consists of a full RFC822 message
with body and a minimal set of header fields, just those necessary to conform
to MIME multipart standards.

The "outer message" should be encrypted and carry a signature according to the
MIME encryption standards. The resulting message is the transport message
which a root entity of type multipart/encrypted.

A minimal set of header fields should be set on the "transport message", as to
permit delivery, without disclosing private information.

The structure of the transport message may be altered in-transit, e.g. through
mailing list agents, or inspection gateways.

Signing and encrypting a message with MIME Security with {{PGPMIME}},
yields a message with the following complete MIME structure, seen
across the encryption layer:

~~~~
    = multipart/encrypted; protocol="application/pgp-encrypted";
      + application/pgp-encrypted [ Version: 1 ]
      + application/octet-stream; name="msg.asc"
        {
          Content-Disposition: inline; filename="msg.asc";
        }
           |
          [ opaque encrypted structure ]
           |
           { minimal headers }
           + multipart/mixed
             + message/rfc822; forwarded="no";
                  |
                 { protected message headers }
                 + multipart/mixed
                   + multipart/alternate
                     + text/plain
                     + text/html
                   + application/octet-stream [ attachmet_1 ]
                   + application/octet-stream [ attachmet_2 ]
             + application/pgp-keys

~~~~

The header fields of the sub-part of type application/octet-stream SHOULD be 
modified to ensure that:

 * the Content-Type header field's
   * "name" parameter is set to the value "msg.asc", and
   * parameter "forwarded" is set to "no", and
 * the Content-Disposition header field value is set to "inline"
   * and the "filename" parameter is set to "msg.asc".

## S/MIME Compatibility

Interoperability and implementation symmetry between PGP/MIME and S/MIME is on
the roadmap of pEp.


# Candidate Header Fields for Header Protection

By default, all headers of the original message SHOULD be wrapped with the
original message, with one exception:

 * the header field "Bcc" MUST NOT be added to the protected headers.



# Stub Outside Headers

The outer message requires a minimal set of headers to be in place for being
eligible for transport. This includes the "From", "To", "Cc", "Bcc", "Subject"
and "Message-ID" header fields. The protocol hereby defined also depends on the
"MIME-Version", "Content-Type", "Content-Disposition" and eventually the
"Content-Transport-Encoding" header field to be present.

Submission and forwarding based on SMTP carries "from" and "receivers"
information out-of-band, so that the "From" and "To" header fields are not
strictly necessary. Nevertheless, "From", "Date", and at least one destination 
header field is mandatory as per {{RFC5322}}. They SHOULD be conserved for 
reliability.

The following header fields should contain a verbatim copy of the header
fields of the inner message:

 * Date
 * From
 * To
 * Cc (*)
 * Bcc (*)

The entries with an asterisk mark (*) should only be set if also present in the
original message.

Clients which follow pEp standards MUST set the header field value for
"Subject" to "=?utf-8?Q?p=E2=89=A1p?=" or "pEp". Clients which do not adhere
to all pEp standards should set the header field value of "Subject" to a
descriptive stub value. An example used in practice is

 * Subject: Encrypted message

The following header fields MUST be initialized with proper values according
to the MIME standards:

 * Content-Type
 * Content-Disposition
 * Content-Transport-Encoding (if necessary)




# Processing Incoming Email under Progressive Header Disclosure

\[\[ TODO \]\]

<!-- 
## Resolving Conflicting Protected and Unprotected Header Fields

Header field values from the transport message MUST NOT be shown, when
displaying the inner message, or the outer message. The inner message MUST
carry all relevant header fields necessary for display. -->


## Processing of Signed-only Email

pEp either engages in a signed-and-encrypted communication or in an unsigned
plaintext communication. Inbound signatures attached to plaintext messages are
duly verified but cannot enhance the perceived quality of the message in the
user interface (while an invalid signature degrades the perception)
{{I-D.birk-pep}}.


## Incoming Filter Processing

The Mail User Agent may implement outgoing filtering of mails, which may veto,
alter, redirect or replicate the messages. The functionality may be
implemented on the mailbox server and be configurable through a well-known
protocol, e.g., by means of The Sieve Mail-Filtering Language {{RFC5490}}, or
be implemented client-side, or in a combination of both.

A mailbox server, which is required to process the full range of possible
filters, is requiring plaintext access to the header fields.

In an End-to-End-encryption context, which pEp enforces by default, upon first
reception of the message the mailbox server is limited to see the transport-
relevant headers of the outer wrapper message. A pEp client configured to trust
the server ("trusted server" setting {{I-D.marques-pep-email}}) will later
download the encrypted message, decrypt it and replace the copy on the server
by the decrypted copy.

### Staged Filtering of Inbound Messages

Inbound messages are expected to be delivered to the inbox while still being
encrypted. At this point in time, server-side filtering can only evaluate the
unprotected header fields in the wrapper message.

In an End-to-End-encryption context, which pEp enforces by default, the mailbox
server is limited to see the transport-relevant headers of the outer wrapper
message only upon first delivery. A pEp client configured to trust the server
("trusted server" setting {{I-D.marques-pep-email}}) will eventually download
the encrypted message, decrypt it locally and replace the copy on the server
by the decrypted copy. Server-side message filters SHOULD be able to detect
such post-processed messages, and apply the pending filters. The client SHOULD
easily reflect the post-filtered messages in the user interface.


## Outgoing Filter Processing

The Mail User Agent may implement outgoing filtering of emails, which may veto,
alter or replicate the email. They may also hint the MUA to store a copy in an
alternate "Sent" folder.

<!-- pEp compliant clients MUST keep all details about cryptography away from the
user interface and keep it transparent to the user (for the exception of
Trustwords comparison). Outgoing filters SHOULD thus be applied on a temporary
representation of the mail with all possible parts unencrypted and unprotected
(the "unprotected representation of the mail"). -->

Filters which veto the sending or do alter the mail or replicate it (e.g.,
mass-mail generators) SHOULD be completed prior to applying protection, and
thus also prior to applying header protection. Redirection to alternate "Sent"
folders MUST NOT be decided prior to applying protection, but MUAs MAY abide
from this restriction if they implement the "trusted server" option and the
option is selected for the specific mailbox server; in this case, MUAs MUST NOT
allow to redirect a message to an untrusted server by these rules, to prevent
information leakage to the untrusted server.

<!-- specify if filter may alter email without additional feedback,
and enforce the no-color-degradation policy -->

\[\[ TODO: Mention implicit filter for minimal color-rating for
message replication. \]\]

\[\[ TODO: How to produce key-export-mails manually this way? That is, what
about non-pEp-mode? \]\]

<!--
## Challenges faced

\[\[ TODO \]\]

Some MUA disclose all content from all nested messages to the user, while
others MUAs display the whole message as an opaque attachment. A few MUAs may
fail to provide an easily workable interaction to access the content of the
attachment, which technically corresponds to an email "saved to a file". All
known MUAs though allow to open or import mails from file, so that the
adaptation is a configuration issue, not one of missing program code.


Clients which inline forwarded messages.

Clients which represent forwarded messages as normal files.
 - Mime-Type
 - Suffix

A non-issue: changing the message structure
 - It is pure interpolation(?)

Dynamic UI between memoryhole logic and header protection

TODO: MUA code structure may not be easily expanded to support decryption and reencryption of messages while displaying messages to the user. Forwarded msg...

Implementation detail: message sorting before decryption

-->


# Security Considerations

\[\[ TODO \]\]


# Privacy Considerations

\[\[ TODO \]\]


# IANA Considerations

This document has no actions for IANA.


{::include ../shared/text-blocks/implementation-status.mkd}


# Acknowledgements

The authors would like to thank the following people who have
provided significant contributions or feedback for the development of
this document: Krista Bennett, Volker Birk, Bernie Hoeneisen and
Hernani Marques.

--- back


# About pEp Design Principles

pretty Easy privacy (pEp) is working on bringing state-of-the-art automatic
cryptography known from areas like TLS to electronic mail (email)
communication. pEp is determined to evolve the existing standards as
fundamentally and comprehensively as needed to gain easy implementation and
integration, and for easy use for regular Internet users. pEp for email wants
to attain to good security practice while still retaining backward
compatibility for implementations widespread.

To provide the required stability as a foundation for good security
practice, pEp for email defines a fixed MIME structure for its innermost
message structure, so to remove most attack vectors which have permitted the
numerous EFAIL vulnerabilities. (TBD: ref)

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 herein referenced, and further described
in {{I-D.marques-pep-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. The pEp
message format is different compared to the S/MIME standard in that the pEp
protocols propose opportunistic End-to-End security and signature, by allowing
the transport of the necessary public key material along with the original
messages.

For the purpose of allowing the insertion of such 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 next.

pEp's proposal is strict in that it requires that the cryptographic services
applied to the protected message MUST include encryption. It also mandates a
fixed MIME structure for the protected message, which always MUST include a
plaintext and optionally an HTML representation (if HTML is used) of the same
message, and requires that all other optional elements to be eventually
presented as attachments.  Alternatively the whole protected message could
represent in turn a wrapped  pEp wrapper, which makes the message structure
fully recursive on purpose (e.g., for the purpose of anonymization through
onion routing).

For the purpose of implementing mixnet routing for email, it is foreseen to
nest pEp messages recursively. A protected message can in turn contain a
protected message due for forwarding. This is for the purpose to increase
privacy and counter the necessary leakage of plaintext addressing in the
envelope of the email.

The recursive nature of the pEp message format allows for the implementation
of progressive disclosure of the necessary transport relevant header fields
just as-needed to the next mail transport agents along the transmission path.



# Document Changelog

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

* draft-luck-lamps-pep-header-protection-03
  * Remove Use Cases / Requirements sections (move to new doc)
  * Adjust title of the document
  * Added note on implementation done of forwarded=no

* draft-luck-lamps-pep-header-protection-02
  * Add Privacy and IANA Considerations sections
  * Added / Adjusted requirements

* draft-luck-lamps-pep-header-protection-01
  * Major rewrite and update of whole document

* draft-luck-lamps-pep-header-protection-00
  * Initial version

# Open Issues

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

* Align with specification for MIME Content-Type message/partial

  * We probably have issues and overlapping specifications about
    encoding for nested message/rfc822 entities, specified in
    {{RFC2046}}. Further study is needed to find and understand the
    issues.





<!--
LocalWords:  utf docname toc sortrefs symrefs Oberer Graben uri Ucom
LocalWords:  Winterthur Hoeneisen GmbH Zuerich bernhard hoeneisen rfc
LocalWords:  ucom ietf melnikov birk trustwords keysync Volker ann cb
LocalWords:  ISOC bnet OpenPGP pgp msg asc pEpkey MUAs UI
LocalWords:  UX Programme Changelog
-->