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.
 
 
 

1196 lines
43 KiB

---
coding: utf-8
title: "Header Protection for S/MIME"
abbrev: Header Protection S/MIME
docname: draft-ietf-lamps-header-protection-00
category: info
stand_alone: yes
pi: [toc, sortrefs, symrefs, comments]
author:
{::include ../shared/author_tags/bernie_hoeneisen.mkd}
{::include ../shared/author_tags/alexey_melnikov.mkd}
#{::include ../shared/author_tags/daniel_kahn_gillmor.mkd}
normative:
# RFC822:
# RFC1847:
# RFC1341:
RFC2045: # MIME part 1 Format of Internet Message Bodies #
RFC2046: # MIME part 2 Media Types #
# RFC2047: # MIME part 3 Message Header Extensions for Non-ASCII Text #
# RFC2048: # MIME part 4 Registration Procedures #
RFC2049: # MIME part 5 Conformance Criteria #
RFC5322: # Internet Message Format #
RFC8551: # S/MIME #
I-D.ietf-lamps-header-protection-requirements:
informative:
# RFC1939: # POP3 #
# RFC8301:
# RFC8463:
RFC3156: # PGP/MIME #
# RFC3501: # IMAP #
RFC4949: # Internet Security Glossary #
# RFC4880: # OpenPGP #
# RFC5321: # SMTP #
# RFC5490:
RFC6376: # DKIM #
RFC6409:
# RFC6532: # internationalized email headers #
RFC7208: # SPF #
# RFC7258:
# RFC7435:
RFC7489: # DMARC #
# RFC7942:
# I-D.melnikov-lamps-header-protection:
I-D.melnikov-iana-reg-forwarded:
I-D.autocrypt-lamps-protected-headers:
# I-D.birk-pep:
I-D.pep-email: I-D.marques-pep-email # TODO: Update reference, once submitted #
# I-D.luck-lamps-pep-header-protection:
# I-D.marques-pep-handshake:
# I-D.birk-pep-trustwords:
# I-D.marques-pep-rating:
{::include ../shared/references/pep-mixnet.mkd}
--- abstract
Privacy and security issues with email header protection in S/MIME
have been identified for some time. However, the desire to fix these
issues has only recently been expressed in the IETF LAMPS Working
Group. The existing S/MIME specification is to be updated
regarding header protection.
This document describes the problem statement, generic use cases, and
the S/MIME specification for header protection.
--- middle
# Introduction
A range of protocols for the protection of electronic mail (email)
exists, which allows to assess the authenticity and integrity of the
email headers section or selected header fields (HF) from the
domain-level perspective, specifically 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 header section and are not capable of providing privacy for the
information contained therein.
The need for means of Data Minimization, which includes data sparseness
and hiding 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 header section
exists for S/MIME version 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/MIME (Pretty Good Privacy) {{RFC3156}} yet.
Several varying implementations of end-to-end protections for email
header sections exist, though the total number of such implementations
appears to be rather low.
Some LAMPS WG participants expressed the opinion that regardless of
the mechanism chosen, it should not be limited to S/MIME, but also
applicable to PGP/MIME.
<!-- Suggestion KRB:
it should be applicable to both S/MIME and PGP/MIME.
-->
This document describes the problem statement ({{problem-statement}}),
generic use cases ({{use-cases}}) and the specification for Header
Protection ({{specification}}).
{{I-D.ietf-lamps-header-protection-requirements}} defines the
requirements that this specification is based on.
<!-- TODO: Decide whether to add the requirements to this document or
leave them in a separate document -->
This document is in early draft state and contains a proposal on which
to base future discussions of this topic. In any case, the final
mechanism is to be determined by the IETF LAMPS WG.
{::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}
* S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. {{RFC8551}})
* PGP/MIME: MIME Security with OpenPGP (cf. {{RFC3156}})
* Message: An Email Message consisting of Header Fields
(collectively called "the Header Section of the message") followed,
optionally, by a Body; cf. {{RFC5322}}.
Note: To avoid ambiguity, this document does not use the terms
"Header" or "Headers" in isolation, but instead always uses "Header
Field" to refer to the individual field and "Header Section" to
refer to the entire collection; cf. {{RFC5322}}.
* Header Field (HF): cf. {{RFC5322}} Header Fields are lines beginning
with a field name, followed by a colon (":"), followed by a field
body (value), and terminated by CRLF; cf. {{RFC5322}}.
* Header Section (HS): The Header Section is a sequence of lines of
characters with special syntax as defined in {{RFC5322}}. It is the
(top) section of a Message containing the Header Fields.
* Body: The Body is simply a sequence of characters that follows the
Header Section and is separated from the Header Section by an empty
line (i.e., a line with nothing preceding the CRLF); cf {{RFC5322}}.
It is the (bottom) section of Message containing the payload of a
Message. Typically, the Body consists of a (multipart) MIME
{{RFC2045}} construct.
* MIME Header Fields: Header Fields describing content of a MIME entity
{{RFC2045}}, in particular the MIME structure. Each MIME Header Field
name starts with "Content-" prefix.
* MIME Header Section (part): The collection of MIME Header Fields.
"MIME Header Section" refers to a Header Sections that contains only
MIME Header Fields, whereas "MIME Header Section part" refers to the
MIME Header Fields of a Header Section that - in addition to MIME
Header Fields - also contains non-MIME Header Fields.
* Essential Header Fields (EHF): The minimum set of Header Fields an
Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
* Header Protection (HP): cryptographic protection of email Header
Sections (or parts of it) for signatures and/or encryption
* Protection Levels (PL): One of 'signature and encryption',
'signature only' or 'encryption only' (cf. {{protection-levels}})
<!--
* Signature and encryption (protection level): If cryptographic
signing and encryption are applied to a message.
* Signature only (protection level): If cryptographic signing, but no
encryption, is applied to a message.
* Encryption only (protection level): If encryption (but no
cryptographic signing) is applied to a message.
-->
* Protected: Protected refers to the parts of a Message where
protection measures of any Protection Level have been applied to.
* Protected Message: A Message that protection measures of any
Protection Levels have been applied to.
* Unprotected: Unprotected refers to the parts of a Message where
no protection measures of any Protection Levels have been applied to.
* Unprotected Message: A Message that no protection measures of any
Protection Levels have been applied to.
* Original Message (OrigM): The message to be protected before any
protection related processing has been applied on the sending side.
* Inner Message (InnerM): The message to be protected, i.e. which
wrapping and protection measures are applied to on the sending side
or the result of decryption and unwrapping on the receiving side
respectively. Typically, the Inner Message is in clear text. The
Inner Message is a subset of (or the same as) the Original Message
(cf. {{inner-msg-hf}}). The Inner Message must be the same on the
sending and the receiving side.
* Outer Message (OuterM): The Message as handed over to the Submission
Entity or received from the last hop respectively. The Outer Message
normally differs on the sending and the receiving side (e.g. new
Header Fields are added by intermediary nodes).
* Receiving User Facing Message (RUFM): The message used for rendering
at the receiving side. Typically this is the same as the Inner
Message.
* Submission Entity: The entity taking care of further processing of
the Message (incl. transport towards the receiver), after protection
measures have been applied to. It typically determines the
destination recipients by reading the To, Cc and Bcc Header Fields
(of the Outer Message).
Note: The Submission Entity varies among implementations, mainly
depending on the stage, where protection measures are applied to: It
could be e.g. a Message Submission Agent (MSA) {{RFC6409}} or
another (proprietary) solution. The latter is particularly relevant,
if protection is implemented as a plugin solution or for mixnet
networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
* Data Minimization: Data sparseness and hiding of all technically
concealable information whenever possible.
# Problem Statement {#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, add more items to the following \]\]
## Privacy {#privacy}
* Data Minimization, which includes data sparseness and hiding all
technically concealable information whenever possible
## Security
* MITM attacks (cf. {{RFC4949}})
## Usability
* User interaction / User experience
## Interoperability
* Interoperability with {{RFC8551}} implementations
# Use Cases {#use-cases}
In the following, the reader can find a list of the generic use cases
that need to be addressed for Messages with Header Protection
(HP). These use cases apply regardless of technology (S/MIME,
PGP/MIME, etc.) used to achieve HP.
## Interactions {#interactions}
The following use cases assume that at least the sending side supports
Header Protection as specified in this document. Receiving sides that
support this specification are expected to be able to distinguish
between Messages that Header Protection -- as specified in this
document -- has been applied to and (legacy) Mail user Agents (MUAs)
not implementing this specification.
\[\[TODO: Verify once solution is stable and update last sentence \]\]
### Main Use Case {#uc-ia-main-use-case}
Both peers (sending and receiving side) (fully) support Header
Protection as specified in this document.
The main use case is specified in {{main-use-case}}.
### Backward Compatibility Use Cases {#uc-ia-backward-compatibility-use-cases}
Regarding backwards compatibility the main distinction is based on
whether or not the receiving side conforms to MIME according to
{{RFC2046}}, ff., which in particular also includes Section 2 of
{{RFC2049}} on "MIME Conformance". In the following an excerpt of
paragraphs relevant in this context:
{::include ../shared/fence-line.mkd}
A mail user agent that is MIME-conformant MUST:
[...]
-- Recognize and display at least the RFC822 message
encapsulation (message/rfc822) in such a way as to
preserve any recursive structure, that is, displaying
or offering to display the encapsulated data in
accordance with its media type.
-- Treat any unrecognized subtypes as if they were
"application/octet-stream".
[...]
A user agent that meets the above conditions is said to be MIME-
conformant. The meaning of this phrase is that it is assumed to be
"safe" to send virtually any kind of properly-marked data to users
of such mail systems, because such systems will at least be able to
treat the data as undifferentiated binary, and will not simply
splash it onto the screen of unsuspecting users.
{::include ../shared/fence-line.mkd}
Note: The compatibility of legacy HP systems with this new solution,
and how to handle issues surrounding future maintenance for these
legacy systems, will be decided by the LAMPS WG.
#### Receiving Side MIME-Conformant {#uc-ia-bc-receiving-side-mime-conformant}
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. The receiving side is MIME-conformant according to
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}),
This use case is specified in {{receiving-side-mime-conformant}}.
Note: This case is expected to just work fine, if the sending side applies
specification for the main use case {{main-use-case}}.
\[\[TODO: Verify once solution is stable and update last sentence \]\]
#### Receiving Side Not MIME-Conformant {#uc-ia-bc-receiving-side-not-mime-conformant}
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. The receiving side is **not** MIME-conformant according
to {{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}})
either.
This use case is specified in {{receiving-side-not-mime-conformant}}.
## Protection Levels {#protection-levels}
The following protection levels need to be considered:
a) Signature and encryption
Messages containing a cryptographic signature, which are also
encrypted.
b) Signature only
Messages containing a cryptographic signature, but which are not
encrypted.
<!--
a cryptographic signature usually within a multipart/signed or
application/pkcs7-mime Content-Type, which doesn't contain any
encrypted layer.
-->
c) Encryption only
Messages that are encrypted, but do not contain a cryptographic
signature.
# Specification {#specification}
This section contains the specification for Header Protection in
S/MIME to update and it clarifies Section 3.1 of {{RFC8551}} (S/MIME
4.0).
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also
incorporate this specification or parts of it.
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. {{protection-levels}}):
Sending and receiving sides MUST implement "signature and
encryption", which is the default to use on the sending side.
Certain implementations MAY decide to send "signature only" messages,
depending on the circumstances and customer requirements. Sending
side MAY and receiving sides MUST implement "signature only".
It generally is NOT RECOMMENDED to send a message with protection
level "encryption only". On the other hand, messages with protection
level "encryption only" might arrive at the receiving side. While not
targeted to protection level "encryption only", this specification is
assumed to also function for "encryption only". Receiving sides SHOULD
implement "encryption only".
Note: It is for further study whether or not more guidance for
handling messages with protection level "encryption only" at the
receiving side is needed.
## Main Use Case {#main-use-case}
This section applies to the main use case, where both peers (sending
and receiving side) (fully) support Header Protection as specified
herein (cf. {{uc-ia-main-use-case}}).
Note: The sending side specification of the main use case is also
applicable to the cases, where the sending side (fully) supports
Header Protection as specified herein, while the receiving side does
not support this specification, but is MIME-conformant according to
{{RFC2045}}, ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
{{uc-ia-bc-receiving-side-mime-conformant}})
Further backward compatibility cases are defined in
{{backward-compatibility-use-cases}}.
### MIME Format {#mime-format}
Currently there are two options in discussion:
1. The option according to the current S/MIME specification
(cf. {{RFC8551}})
1. An alternative option that is based on the former "memory hole"
approach (cf. {{I-D.autocrypt-lamps-protected-headers}})
#### S/MIME Specification {#option-smime-spec}
As per S/MIME version 3.1 and later (cf. {{RFC8551}}), 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.
To help the receiving side to distinguish between forwarded and
wrapped message, a Content-Type header field parameter "forwarded" is
added as defined in {{I-D.melnikov-iana-reg-forwarded}}. Certain
mailing applications might display the Inner Message as attachment
otherwise.
The MIME structure of an Email message looks as follows:
{::include ../shared/fence-line.mkd}
<Outer Message Header Section (unprotected)>
<Outer Message Body (protected)>
<MIME Header Section (wrapper)>
<Inner Message Header Section>
<Inner Message Body>
{::include ../shared/fence-line.mkd}
The following example demonstrates how header section and payload of a
protected 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 Message Header Section. Lines
prepended by "I: " are the Inner Message Header Section. Lines
prepended by "W: " are the wrapper (MIME Header Section):
{::include ../shared/fence-line.mkd}
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: To: somebody@example.net
O: MIME-Version: 1.0
O: 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
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@m.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--
{::include ../shared/fence-line.mkd}
The Outer Message Header Section is unprotected, while the remainder
(Outer Message Body) is protected. The Outer Message Body consists of
the wrapper (MIME Header Section) and the Inner Message (Header
Section and Body).
The wrapper is a simple MIME Header Section with media type
"message/RFC822" containing a Content-Type header field parameter
"forwarded=no" followed by an empty line.
The Inner Message Header Section is the same as (or a subset of) the
Original Message Header Section (cf. {{inner-msg-hf}}).
The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any MIME structure.
<!--
Alexey: I think this is just saying "The Original Message itself may contain any MIME structure"
but in a bad way, because "multipart/mixed" is not the only choice here:
There may also be an additional MIME layer with media type
"multipart/mixed" in the Outer Message Body to contain the Inner
Message (wrapped in a "message/RFC822") along with other MIME part(s).
-->
#### Alternative Option Autocrypt "Protected Headers" (Ex-"Memory Hole") {#option-ex-memory-hole}
An alternative option (based on the former autocrypt "Memory Hole" approach)
to be considered, is described in
{{I-D.autocrypt-lamps-protected-headers}}.
Unlike the option described in {{option-smime-spec}}, this option does
not use a "message/RFC822" wrapper to unambiguously delimit the Inner
Message.
Before choosing this option, two issues must be assessed to ensure, no
interoperability issues result from it:
1. How current MIME parser implementations treat non-MIME Header
Fields, which are not part of the outermost MIME entity and not
part of a message wrapped into a MIME entity of media type
"message/rfc822", and how such messages are rendered to the user.
{{I-D.autocrypt-lamps-protected-headers}} provides some examples
for testing this.
2. MIME-conformance, i.e. whether or not this option is (fully)
MIME-conformant {{RFC2045}} ff., in particular also Section 5.1. of
{{RFC2046}} on "Multipart Media Type). In the following an excerpt
of paragraphs that may be relevant in this context:
{::include ../shared/fence-line.mkd}
The only header fields that have defined meaning for body parts
are those the names of which begin with "Content-". All other
header fields may be ignored in body parts. Although they
should generally be retained if at all possible, they may be
discarded by gateways if necessary. Such other fields are
permitted to appear in body parts but must not be depended on.
"X-" fields may be created for experimental or private
purposes, with the recognition that the information they
contain may be lost at some gateways.
{::include ../shared/fence-line.mkd}
{::include ../shared/fence-line.mkd}
NOTE: The distinction between an RFC 822 message and a body
part is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is a
JPEG image. In order to represent the latter, the body part
must have "Content-Type: message/rfc822", and its body (after
the blank line) must be the encapsulated message, with its own
"Content-Type: image/jpeg" header field. The use of similar
syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which
parts actually are messages, a "digest" subtype is also
defined.)
{::include ../shared/fence-line.mkd}
The MIME structure of an Email message looks as follows:
{::include ../shared/fence-line.mkd}
<Outer Message Header Section (unprotected)>
<Outer Message Body (protected)>
<Inner Message Header Section>
<Inner Message Body>
{::include ../shared/fence-line.mkd}
The following example demonstrates how the header section and payload
of a protected body part might appear. 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.
{::include ../shared/fence-line.mkd}
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: MIME-Version: 1.0
O: 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@m.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--
{::include ../shared/fence-line.mkd}
The Outer Message Header Section is unprotected, while the remainder
(Outer Message Body) is protected. The Outer Message Body consists of
the Inner Message (Header Section and Body).
The Inner Message Header Section is the same as (or a subset of) the
Original Message Header Section (cf. {{inner-msg-hf}}).
The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any MIME structure.
<!--
Alexey: as above: I don't think this helps.
Either add an example with a more complicated MIME structure,
or delete this text.
There may also be an additional MIME layer with media type
"multipart/mixed" in the Outer Message Body to contain the Inner
Message along with other MIME part(s).
-->
### Inner Message Header Fields {#inner-msg-hf}
It is RECOMMENDED that the Inner Messages contains all the Header
Fields of the Original Message with the exception of the following
Header Field, which MUST NOT be included within the Inner Message nor
within any other protected part of the message:
* Bcc
\[\[ TODO: Bcc handling needs to be further specified (see also
{{bcc-handling}}). Certain MUAs cannot properly decrypt messages
with Bcc recipients. \]\]
### Wrapper {#wrapper}
The wrapper is a simple MIME Header Section followed by an empty line
preceding the Inner Message (inside the Outer Message Body). The media
type of the wrapper MUST be "message/RFC822" and MUST contain the
Content-Type header field parameter "forwarded=no" as defined in
{{I-D.melnikov-iana-reg-forwarded}}. The wrapper delimits unambiguously
the Inner Message from the rest of the message.
### Outer Message Header Fields {#outer-msg-hf}
To maximize Privacy, it is strongly RECOMMENDED to follow the
principle of Data Minimization (cf. {{privacy}}).
However, the Outer Message Header Section SHOULD contain the Essential
Header Fields and, in addition, MUST contain the Header Fields of the
MIME Header Section part to describe the encryption or signature as
per {{RFC8551}}.
The following Header Fields are defined as the Essential Header Fields:
* From
* To (if present in the Original Message)
* Cc (if present in the Original Message)
* Bcc (if present in the Original Message, see also {{inner-msg-hf}}
and {{bcc-handling}})
* Date
* Message-ID
* Subject
Further processing by the Submission Entity normally depends on part
of these Header Fields, e.g. From and Date HFs are required by
{{RFC5322}}. Furthermore, not including certain Header
Fields may trigger spam detection to flag the message and/or
lead to user experience (UX) issues.
For further Data Minimization, the value of the Subject Header Field
SHOULD be obfuscated. In addition, the value of other Essential Header
Fields MAY be obfuscated. Further Header Fields MAY be obfuscated,
though simply not adding those to the Outer Message Header Section
SHOULD be preferred over obfuscation. Header Field obfuscation is
further specified in {{obfuscation-outer-HF}}. Header Fields not
obfuscated should contain the same values as in the Original Message.
The MIME Header Section part is the collection of MIME Header Fields
describing the following MIME structure as defined in {{RFC2045}}.
A MIME Header Section part typically includes the following Header
Fields:
* Content-Type
* Content-Transfer-Encoding
* Content-Disposition
<!--
Alexey: I don't find separation between MIME Header Section and
full Header Section to be useful. They have exactly the same parsing
rules.
-->
The following example shows the MIME Header Section part of an S/MIME signed
message (using application/pkcs7-mime with SignedData):
{::include ../shared/fence-line.mkd}
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
{::include ../shared/fence-line.mkd}
Depending on the scenario, further Header Fields MAY be exposed in the
Outer Message Header Section, which is NOT RECOMMENDED unless
justified. Such Header Fields may include e.g.:
* References
* Reply-To
* In-Reply-To
<!--
Alexey: the above header fields would be need if IMAP server side threading is to be used.
-->
#### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
If the values of the following Outer Message Header Fields are
obfuscated, those SHOULD assume the following values:
~~~
* Subject: ...
* Message-ID: <new randomly generated Message-ID>
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
~~~
\[\[ TODO: Consider alternatives for Date e.g. set to Monday 9am of
the same week. \]\]
In certain implementations also the From, To, and/or Cc Header Field
MAY be obfuscated. Those may be replaced by e.g.
* To: Obfuscated <anonymous@anonymous.invalid>
Such implementations may need to ensure that the Submission Entity has
access to the content of these Header Fields in clear text and is
capable of processing those. This is particularly relevant, if
proprietary Submission Entities are used.
A use case for obfuscation of all Outer Message Header Fields is
mixnet networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
Note: It is for further study to what extent Header Field obfuscation
adversely impacts spam filtering.
<!-- suggestion KRB:
"Further studies of the impact that Header Field obfuscation has on
spam filtering are needed."
-->
### Receiving User Facing Message Header Fields {#rufm-hf}
The Receiving User Facing Message SHOULD be a verbatim copy of the
Inner Message.
<!-- Alternative
The Receiving User Facing Message is constructed as follows:
* The Header Section of the Receiving User Facing Message MUST consist
of the Outer Message Header Fields that are not contained in the
Inner Message Header Section, and the Inner Message Header Fields
(i.e. the Inner Message Header Field MUST always take precedence).
* The Body of the Receiving User Facing Message Body MUST be the same
as the Inner Message Body.
\[\[ TODO: Do we need to take special care for HFs, which may appear
multiple times, e.g. Received HF?
Alexey: None of the header fields that we want protecting are allowed to
appear multiple times.
The header fields that can appear multiple times are usually trace header fields:
Received, Authentication-Results, etc. They are prepended to the outer
Header Section and can never be protected.
So I think this is just a long way of saying that no extra text is needed here,
unless you want the document to explain the above.
\]\]
-->
### Header Field Flow
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/message_orig_outer_inner_rufm.mkd}
{::include ../shared/fence-line.mkd}
Legend:
* OuterM(S): Outer Message (OuterM) at sending side (before handing it
over to the Submission Entity)
* OuterM(R): Outer Message at receiving side (as received by the last
hop, before decryption and/or signature verification is applied to)
* InnerM: Inner Message (that protection is applied to)
* RUFM: Receiving User Facing Message
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
* Wrapper: MIME Header Section; with media type (message/RFC822) to
unambiguously delimit the inner message from the rest of the
message.
* MIME-HSp: MIME Header Section part to describe the encryption or
signature as per {{RFC8551}}
* Trace-HF: Header Fields added in Transit (between sending and
receiving side) as per {{RFC5322}}
* \>: taken over / copied from last column
* \=: propagates unchanged, unless something unusual (e.g. attack)
happens
* \*: HF that is often not present (also further HFs, e.g. To, may not
be present). If a HF is not present, naturally it can neither be
taken over nor propagated.
* (new) / (OrigM): HF or MIME-HSp is generated depending on the
decision in {{sending-side-step-1}}, while '(new)' / '(OrigM)'
designate the default.
### Sending Side Message Processing {#sending-side-message-processing}
For a protected message the following steps are applied before a
message is handed over to the Submission Entity:
#### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1}
The entity applying protection to a message must decide:
* Which Protection Level (signature and/or encryption) is applied to
the message? This depends on user request and/or local policy as
well as availability of cryptographic keys.
* Which Header Fields of the Original Message shall be part of the
Outer Message Header Section? This typically depends on local
policy. By default the Essential Header Fields are part of the Outer
Message Header Section; cf. {{outer-msg-hf}}.
* Which of these Header Fields are to be obfuscated? This depends on
local policy and/or specific Privacy requirements of the user. By
default only the Subject Header Field is
obfuscated; cf. {{obfuscation-outer-HF}}.
#### Step 2: Compose the Outer Message Header Section {#sending-side-step-2}
Depending on the decision in {{sending-side-step-1}}, compose the
Outer Message Header Section. (Note that this also includes the
necessary MIME Header Section part for the following protection
layer.)
Outer Header Fields that are not obfuscated should contain the same
values as in the Original Message (except for MIME Header Section
part, which depends on the protection level selected in
{{sending-side-step-1}}).
#### Step 3: Apply Protection to the Original Message {#sending-side-step-3}
Depending on the Protection Level selected in {{sending-side-step-1}},
apply signature and/or encryption to the Original Message, including
the wrapper (as per {{RFC8551}}), and set the result to the message as
Outer Message Body.
The resulting (Outer) Message is then typically handed over to the
Submission Entity.
\[\[ TODO: Example \]\]
### Receiving Side Message Processing
When a protected message is received, the following steps are applied:
#### Step 1: Decrypt message and/or check signature {#receiving-side-step-1}
Depending on the protection level, the received message is decrypted
and/or its signature is checked as per {{RFC8551}}.
#### Step 2: Construct the Receiving User Facing Message {#receiving-side-step-2}
The Receiving User Facing Message is constructed according to
{{rufm-hf}}.
The resulting message is handed over for further processing, which
typically involves rendering it for the user.
Note: Further study is needed to determine whether or not the Outer
Message Header Section, as received from the last hop, is
preserved for the user, and if so, how this is to be achieved.
## Backward Compatibility Use Cases {#backward-compatibility-use-cases}
### Receiving Side MIME-Conformant {#receiving-side-mime-conformant}
This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the
receiving side does not support this specification, but is
MIME-conformant according to {{RFC2045}},
ff. (cf. {{uc-ia-backward-compatibility-use-cases}}) and
{{uc-ia-bc-receiving-side-mime-conformant}})
The sending side specification of the main use case
(cf. {#main-use-case}}) MUST ensure that receiving sides, that do not
support this specification, but are MIME-conformant according to
{{RFC2045}}, ff. can still recognize and display the Inner Message (or
rather the RUFM) in such a way as to preserve any recursive structure,
that is, displaying or offering to display the encapsulated data in
accordance with its media type (cf. {{RFC2049}}, Section 2).
\[\[TODO: Verify once solution is stable and update last sentence \]\]
### Receiving Side Not MIME-Conformant {#receiving-side-not-mime-conformant}
This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the
receiving side neither supports this specification and
**nor** is MIME-conformant according to {{RFC2045}}, ff.
(cf. {{uc-ia-backward-compatibility-use-cases}) and
{{uc-ia-bc-receiving-side-not-mime-conformant}}).
{{I-D.autocrypt-lamps-protected-headers}} describes a possible way to
achieve backward compatibility with existing S/MIME (and PGP/MIME)
implementations that predate this specification and are not
MIME-conformant (Legacy Display) either. It mainly focuses on email clients
that do not render emails using header protection (in a user friendly
manner) and may confuse the user. While this has been observed
occasionally in PGP/MIME (cf. {{RFC3156}}), the extent of this problem
with S/MIME implementations is still unclear. (Note: At this time,
none of the samples in {{I-D.autocrypt-lamps-protected-headers}} apply
header protection as specified in Section 3.1 of {{RFC8551}}, which is
wrapping as Media Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver be discovered, the Legacy Display format described in
{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
mitigate those issues (cf. {{backward-compatibility-use-cases}}).
Another variant of backward compatibility has been implemented by pEp
{{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp
has implemented this for PGP/MIME, but not yet S/MIME.
# Security Considerations
\[\[ TODO \]\]
# Privacy Considerations
\[\[ TODO \]\]
# IANA Considerations
This document requests no action from IANA.
\[\[ RFC Editor: This section may be removed before publication. \]\]
# Acknowledgments
The authors would like to thank the following people who have provided
helpful comments and suggestions for this document: Berna Alp, Claudio
Luck, Daniel Kahn Gillmor, David Wilson, Hernani Marques, Krista
Bennett, Kelly Bristol, Robert Williams, Sofia Balicka, Steve Kille,
Volker Birk, and Wei Chuang.
--- back
<!-- =========================================================================== -->
# Additional information
## Stored Variants of Messages with Bcc {#bcc-handling}
Messages containing at least one recipient address in the Bcc
header field may appear in up to three different variants:
1. The message for the recipient addresses listed in To or Cc
header fields, which must not include the Bcc header field neither
for signature calculation nor for encryption.
2. The message(s) sent to the recipient addresses in the Bcc header
field, which depends on the implementation:
a) One message for each recipient in the Bcc header field
separately, with a Bcc header field containing only the address
of the recipient it is sent to.
b) The same message for each recipient in the Bcc header field with
a Bcc header field containing an indication such as "Undisclosed
recipients", but no addresses.
c) The same message for each recipient in the Bcc header field
which does not include a Bcc header field (this message is
identical to 1. / cf. above).
3. The message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original message,
i.e., with all recipient addresses.
The most privacy preserving method of the alternatives (2a, 2b, and
2c) is to standardize 2a, as in the other cases (2b and 2c),
information about hidden recipients is revealed via keys. In any case,
the message has to be cloned and adjusted depending on the recipient.
<!-- =========================================================================== -->
# Document Changelog
\[\[ RFC Editor: This section is to be removed before publication \]\]
* draft-ietf-lamps-header-protection-00
* Initial version (text partially taken over from
{{I-D.ietf-lamps-header-protection-requirements}}
# Open Issues
\[\[ RFC Editor: This section should be empty and is to be removed
before publication. \]\]
* Ensure "protected header" (Ex-Memory-Hole) option is (fully)
compliant with the MIME standard, in particular also {{RFC2046}},
Section 5.1. (Multipart Media Type) {{option-ex-memory-hole}}.
* Decide on format of obfuscated HFs, in particular Date HF
({{obfuscation-outer-HF}})
* Impact on spam filtering, if HFs are obfuscated
({{obfuscation-outer-HF}})
* More examples (e.g. in {{sending-side-message-processing}})
* Should Outer Message Header Section (as received) be preserved for
the user? ({{receiving-side-step-2}})
* Change adding Content-Type header field parameter "forwarded" from
SHOULD to MUST ({{wrapper}})?
* Decide on whether or not merge requirements from
{{I-D.ietf-lamps-header-protection-requirements}} into this
document.
* Decide what parts of {{I-D.autocrypt-lamps-protected-headers}} to
merge into this document.
* Enhance Introduction and Problem Statement sections
* Decide on whether or not specification for more legacy HP
requirements should be added to this document
* Verify ability to distinguish between Messages with Header
Protection as specified in this document and legacy clients and
update {{interactions}} accordingly.
* Verify simple backward compatibility case (Receiving Side
MIME-Conformant) is working; once solution is stable and update
paragraphs in {#uc-ia-bc-receiving-side-mime-conformant}} and
{{receiving-side-mime-conformant}} accordingly.
* Improve definitions in {{protection-levels}}
* Privacy Considerations {{privacy-considerations}}
* Security Considerations {{security-considerations}}
<!--
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 req SMTP WG
LocalWords: UX Programme Changelog IMAP DKIM DMARC DomainKeys HB HFs
LocalWords: implementer's pkcs SignedData cryptographically LF iana
LocalWords: prio charset Bcc LSS LSR wrt DKG prepending TBD fc KRB
LocalWords: recurse TLS EFAIL cleartext plaintext mixnet MMHS CRLF
LocalWords: anonymization Alexey Isode ascii prepended micalg EHF uc
LocalWords: sha cbe Chuang Kille cryptographic interoperability RUFM
LocalWords: roadmap autocrypt OrigM InnerM OuterM MSA MTA ia bc bcc
LocalWords: subtypes smime rufm HSp Berna Balicka
-->