Internet-Draft | Cryptographic MIME Header Protection | June 2024 |
Gillmor, et al. | Expires 5 December 2024 | [Page] |
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message.¶
This document updates the S/MIME specification (RFC8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. The Header Protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://dkg.gitlab.io/lamps-header-protection/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/.¶
Discussion of this document takes place on the LAMPS Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.¶
Source for this draft and an issue tracker can be found at https://gitlab.com/dkg/lamps-header-protection.¶
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 5 December 2024.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Privacy and security issues regarding e-mail Header Protection in S/MIME and PGP/MIME have been identified for some time. 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. For example, lack of Header Protection allows an attacker to substitute the message subject and/or author.¶
This document describes two different schemes for how message headers can be cryptographically protected, and provides guidance for implementers of MUAs that generate and interpret such messages. It uses the term "Legacy MUA" to refer to an MUA that does not implement either scheme. This document takes particular care to ensure that messages interact reasonably well with Legacy MUAs.¶
This document addresses two different schemes for cryptographically protecting e-mail Header Sections or fields and provides guidance to implementers. One scheme ("Injected Headers") is more interoperable with Legacy MUAs and is mandatory to implement and interpret. The other, older scheme ("Wrapped Message") is described here to enable interpretation of archived messages.¶
The older scheme was first specified in S/MIME 3.1 ([RFC8551]), and involves wrapping a message/rfc822
or message/global
MIME object with a Cryptographic Envelope around the message to protect.
This document calls this scheme "Wrapped Message", and it updates the scheme described in that document, effectively replacing the final two paragraphs of Section 3.1 of [RFC8551].
However, experience has shown that even the updated "Wrapped Message" form does not interact well with some Legacy MUAs (see Section 1.2).¶
The more interoperable "Injected Headers" scheme of Header Protection is introduced in this document, and is preferred over the "Wrapped Message" scheme.
In the "Injected Headers" scheme, the protected Header Fields are placed directly on the Cryptographic Payload without using an intervening message/*
MIME object.
See Section 2.5.6 and Section 2.7.3 for more details.¶
Several Legacy MUAs have revealed rendering issues when dealing with a message that uses the Wrapped Message Header Protection scheme.¶
In some cases, some mail user agents cannot render message/rfc822
message subparts at all, in violation of baseline MIME requirements as described on page 5 of [RFC2049].
This leaves all Wrapped Messages unreadable by any recipient using such an MUA.¶
In other cases, the user sees an attachment suggesting a forwarded e-mail message, which -- in fact -- contains the protected e-mail message that should be rendered directly. In most of these cases, the user can click on the attachment to view the protected message.¶
However, viewing the protected message as an attachment in isolation may strip it of any security indications, leaving the user unable to assess the cryptographic properties of the message. Worse, for encrypted messages, interacting with the protected message in isolation may leak contents of the cleartext, for example, if the reply is not also encrypted.¶
A Legacy MUA dealing with an encrypted message that has some Header Fields obscured using the Injected Headers scheme will not render the obscured Header Fields to the user at all. A workaround "Legacy Display" mechanism is provided in this document, which most Legacy MUAs should render to the user, albeit not in the same location that the Header Fields would normally be rendered.¶
Users generally do not understand the distinction between message body and message header. When an e-mail message has cryptographic protections that cover the message body, but not the Header Fields, several attacks become possible.¶
For example, a Legacy Signed Message has a signature that covers the body but not the Header Fields. An attacker can therefore modify the Header Fields (including the Subject header) without invalidating the signature. Since most readers consider a message body in the context of the message's Subject header, the meaning of the message itself could change drastically (under the attacker's control) while still retaining the same cryptographic indicator of authenticity.¶
In another example, a Legacy Encrypted Message has its body effectively hidden from an adversary that snoops on the message. But if the Header Fields are not also encrypted, significant information about the message (such as the message Subject) will leak to the inspecting adversary.¶
However, if the sending and receiving MUAs ensure that cryptographic protections cover the message Header Section as well as the message body, these attacks are defeated.¶
If the sending MUA is unwilling to generate such a fully protected message due to the potential for rendering, usability, deliverability, or security issues, these defenses cannot be realized.¶
The sender cannot know what MUA (or MUAs) the recipient will use to handle the message. Thus, an outbound message format that is backward compatible with as many legacy implementations as possible is a more effective vehicle for providing the whole-message cryptographic protections described above.¶
This document aims for backward compatibility with Legacy MUAs to the extent possible. In some cases, like when a user-visible header like the Subject is cryptographically hidden, a Legacy MUA will not be able to render or reply to the message exactly same way as a conformant MUA would. But accommodations are described here that ensure a rough semantic equivalence for Legacy MUA even in these cases.¶
A message with perfect cryptographic protections that cannot be delivered is less useful than a message with imperfect cryptographic protections that can be delivered. Senders want their messages to reach the intended recipients.¶
Given the current state of the Internet mail ecosystem, encrypted messages in particular cannot shield all of their Header Fields from visibility and still be guaranteed delivery to their intended recipient.¶
This document accounts for this concern by providing a mechanism (Section 2.5.2) that prioritizes initial deliverability (at the cost of some header leakage) while facilitating future message variants that shield more header metadata from casual inspection.¶
A separate pair of protocols also provides some cryptographic protection for the e-mail message header integrity: DomainKeys Identified Mail (DKIM) [RFC6376], as used in combination with Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. This pair of protocols provides a domain-based reputation mechanism that can be used to mitigate some forms of unsolicited e-mail (spam).¶
However, the DKIM+DMARC suite provides cryptographic protection at a different scope than the mechanisms described here. In particular, the message integrity and authentication signals provided by DKIM+DMARC correspond to the domain name of the sending e-mail address, not the sending address itself, so the DKIM+DMARC suite does not provide end-to-end protection. DKIM and DMARC are typically applied to messages by (and interpreted by) mail transfer agents, not mail user agents. The mechanisms in this document are typically applied to messages by (and interpreted by) mail user agents.¶
Furthermore, the DKIM+DMARC suite only provides cryptographic integrity and authentication, not encryption. So cryptographic confidentiality is not available from that suite.¶
The DKIM+DMARC suite can be used on any message, including messages formed as described in this document. There should be no conflict between these schemes.¶
Though not strictly e-mail, similar protections have been in use on Usenet for signing and verification of message headers for years. See [PGPCONTROL] and [PGPVERIFY-FORMAT] for more details. Like DKIM, these Usenet control protections offer only integrity and authentication, not encryption.¶
This document describes end-to-end cryptographic protections for e-mail messages in reference to S/MIME ([RFC8551]).¶
Comparable end-to-end cryptographic protections can also be provided by PGP/MIME ([RFC3156]).¶
The mechanisms in this document should be applicable in the PGP/MIME protections as well as S/MIME protections, but analysis and implementation in this document focuses on S/MIME.¶
To the extent that any divergence from the mechanism described here is necessary for PGP/MIME, that divergence is out of scope for this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The key words "SPECIFICATION REQUIRED" and "IETF REVIEW" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC8126].¶
The following terms are defined for the scope of this document:¶
S/MIME: Secure/Multipurpose Internet Mail Extensions (see [RFC8551])¶
Message: An E-Mail Message consisting of Header Fields (collectively called "the Header Section of the message") followed, optionally, by a Body; see [RFC5322].¶
Note: To avoid ambiguity, this document avoids using 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.¶
Header Field: A Header Field includes a field name, followed by a colon (":"), followed by a field body (value), and terminated by CRLF; see Section 2.2 of [RFC5322] for more details.¶
Header Section: The Header Section is a sequence of lines of characters with special syntax as defined in [RFC5322]. The Header Section of a Message contains the Header Fields associated with the Message itself. The Header Section of a MIME part (that is, a subpart of a message) typically contains Header Fields associated with that particular MIME part.¶
Body: The Body is the part of a Message 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); see [RFC5322]. It is the (bottom) section of a Message containing the payload of a Message. Typically, the Body consists of a (possibly multipart) MIME [RFC2045] construct.¶
Header Protection (HP): cryptographic protection of e-mail Header Sections (or parts of it) by means of signatures and/or encryption.¶
Cryptographic Layer, Cryptographic Payload, Cryptographic Envelope, Cryptographic Summary, Structural Header Fields, Main Body Part, User-Facing Header Fields, and MUA are all used as defined in [I-D.ietf-lamps-e2e-mail-guidance]¶
Legacy MUA: an MUA that does not understand Header Protection as described in this document. A Legacy Non-Crypto MUA is incapable of doing any end-to-end cryptographic operations. A Legacy Crypto MUA is capable of doing cryptographic operations, but does not understand or generate messages with Header Protection.¶
Legacy Signed Message: an e-mail message that was signed by a Legacy MUA (and therefore has no cryptographic authenticity or integrity protections on its Header Fields.¶
Wrapped Message: The Header Protection scheme that uses the mechanism described in [RFC8551], where the Cryptographic Payload is a message/rfc822
or message/global
MIME object, augmented with a Content-Type parameter to indicate that this is the explicit intent.
(see Section 2.2).¶
Injected Headers: The Header Protection scheme that uses the mechanism described in this document (see Section 2.1), where the protected Header Fields are inserted on the Cryptographic Payload directly.¶
Header Confidentiality Policy (HCP): a functional specification of which Header Fields should be removed or obscured when composing an encrypted message with Header Protection. An HCP is considered more "conservative" when it removes or obscures fewer Header Fields. When it removes or obscures more Header fields, it is more "ambitious". See Section 2.5.2.¶
Ordinary User: a user of an MUA who follows a simple and minimal experience, focused on sending and receiving e-mails. A user who opts into advanced configuration, expert mode, or the like is not an "Ordinary User".¶
This document describes sensible, simple behavior for a program that generates an e-mail message with standard end-to-end cryptographic protections, following the guidance in [I-D.ietf-lamps-e2e-mail-guidance]. An implementation conformant to this document will produce messages that have cryptographic protection that covers the message's Header Fields as well as its body.¶
This document also describes sensible, simple behavior for a program that interprets such a message, in a way that can take advantage of these protections covering the Header Fields as well as the body.¶
The message generation guidance aims to minimize negative interactions with any Legacy receiving MUA while providing actionable cryptographic properties for modern receiving clients.¶
In particular, this document focuses on two standard types of cryptographic protection that cover the entire message:¶
The message composition guidance in this document (in Section 2.5.6) aims to provide minimal disruption for any Legacy MUA that receives such a message. However, a Legacy MUA by definition does not implement any of the guidance here. Therefore, the document does not attempt to provide guidance for Legacy MUAs directly.¶
Furthermore, this document does not explicitly contemplate other variants of cryptographic message protections, including any of these:¶
Encrypted-only message (Without a cryptographic signature. See Section 5.3 of [I-D.ietf-lamps-e2e-mail-guidance].)¶
Triple-wrapped message¶
Signed message with multiple signatures¶
Encrypted message with a cryptographic signature outside the encryption.¶
All such messages are out of scope of this document.¶
As mentioned in Section 1.1, this document describes two ways to provide end-to-end cryptographic protection for an e-mail message that includes all Header Fields known to the sender at message composition time. This document also specifies a new Header Field: HP-Outer (see Section 2.5.3).¶
When composing a message with end-to-end cryptographic protections, an MUA SHOULD apply Header Protection. A sending MUA MUST be able to generate the Injected Headers scheme (Section 2.5.6), and MAY generate the Wrapped Message scheme (Section 2.5.7). The MUA implementer can choose between the two schemes (see Section 4.3).¶
A compatible MUA SHOULD use Injected Headers when composing a new message with end-to-end cryptographic protections, since a message structured with Injected Headers is more likely to be usable by both legacy and compatible MUAs.¶
A receiving MUA MUST be able to handle both Header Protection schemes, as described in Section 2.7.¶
A message that uses the Injected Headers scheme has protected Header Fields in the Header Section of the Cryptographic Payload.¶
For an encrypted message that has at least one User-Facing Header Field (see Section 1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]) removed or obscured outside of the Cryptographic Payload, those Header Fields MAY be duplicated into decorative copies in the Main Body MIME part of the Cryptographic Payload itself. These decorative copies within the message are known as "Legacy Display Elements".¶
Such a Legacy Display Element enables users of a Legacy receiving MUA -- that doesn't yet understand how to interpret or display the Injected Headers scheme -- to view the removed/obscured Header Fields. See Section 3.1 for more details about how the ecosystem could shift so that a sending MUA could avoid the need to generate any Legacy Display Element.¶
Composing a message with the Injected Headers scheme is described in Section 2.5.6. Rendering such a message is described in Section 2.7.3. Example message composition and reply can be seen in Appendix C. Example message rendering which strips Legacy Display Elements can be seen in Appendix D.¶
A message that uses the Wrapped Message scheme has a Cryptographic Payload of a single message/rfc822
(or message/global
) MIME object, which itself contains the original message (including the protected Header Section).¶
The Wrapped Message Header Protection scheme is very similar to that described in Section 3.1 of [RFC8551]. The main augmentations this document provides to that scheme are:¶
an explicit discussion of how to obscure or remove Header Fields,¶
an additional hp="clear"
or hp="cipher"
parameter to the Content-Type
Header Field of the Cryptographic Payload to indicate the explicit intent,¶
an additional hp-scheme="wrapped"
parameter to the same Content-Type
Header Field to indicate the specific scheme in use,¶
a recommendation to mark such a Wrapped Message as "Content-Disposition: inline
" to encourage Legacy MUAs to render the inner message directly rather than treating it as an attachment, and¶
a mechanism the recipient of an encrypted message can use to explicitly derive what Header Fields were removed or obscured by the sender (the HP-Outer
mechanism).¶
Composing a message with the Wrapped Message scheme is described in Section 2.5.7. Rendering such a message is described in Section 2.7.4.¶
This specification defines a parameter for the Content-Type
Header Field named hp
(for Header Protection).
Its value is only relevant on the Content-Type
Header Field at the root of the Cryptographic Payload.
When generating a message, an MUA MUST add this parameter only to the Content-Type
Header Field at the root of the message's Cryptographic Payload.
When consuming a message, an MUA MUST ignore this parameter when it encounters it anywhere other than the root of the message's Cryptographic Payload.¶
The parameter's defined values describe the sender's cryptographic intent when producing the message:¶
hp Value | Authenticity | Integrity | Confidentiality | Description |
---|---|---|---|---|
"clear"
|
yes | yes | no | This message has been signed by the sender with Header Protection |
"cipher"
|
yes | yes | yes | This message has been signed by the sender, with Header Protection, and is encrypted to the recipients |
A sending implementation MUST NOT produce a Cryptographic Payload with parameter hp="cipher"
for an non-encrypted message (that is, where none of the Cryptographic Layers in the Cryptographic Envelope of the message provide encryption).
Likewise, if a sending implementation is sending an encrypted message with Header Protection, it MUST emit an hp="cipher"
parameter, regardless of the HCP in use.¶
Note that hp="cipher"
indicates that the message itself has been encrypted by the sender to the recipients, but makes no assertions about which Header Fields have been removed or obscured.
This can be derived from the Cryptographic Payload itself (see Section 2.5.4).¶
A receiving implementation MUST NOT mistake the presence of an hp="cipher"
parameter in the Cryptographic Payload for the actual presence of a Cryptographic Layer that provides encryption.¶
This document recommends the Injected Headers scheme, and the presence of the hp=
parameter in the Content-Type
of the Cryptographic Payload implies the use of that scheme by default.
If the message does Header Protection using the Wrapped Message scheme, it MUST also add an hp-scheme="wrapped"
parameter to the Content-Type
of the Cryptographic Payload.¶
hp-scheme Value | Header Protection Scheme Used |
---|---|
(no hp-scheme parameter present) |
Injected Headers |
"wrapped"
|
Wrapped Message |
This section describes the process an MUA should use to apply cryptographic protection to an e-mail message with Header Protection.¶
As a baseline, we consider the typical message composition process of a Legacy Crypto MUA which does not provide any Header Protection.¶
This process is described in Section 5.1 of [I-D.ietf-lamps-e2e-mail-guidance]. We replicate it here for reference:¶
origbody
: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part).
As a well-formed MIME tree, origbody
already has structural Header Fields (Content-*
) present.¶
origheaders
: the intended non-structural Header Fields for the message, represented here as a list of (h,v)
pairs, where h
is a Header Field name and v
is the associated value.
Note that these are Header Fields that the MUA intends to be visible to the recipient of the message.
In particular, if the MUA uses the Bcc
Header Field during composition, but plans to omit it from the message (see Section 3.6.3 of [RFC5322]), it will not be in origheaders
.¶
crypto
: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y").
This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output.¶
The algorithm returns a MIME object that is ready to be injected into the mail system:¶
When composing an encrypted message with Header Protection, the composing MUA needs a Header Confidentiality Policy (HCP).
In this document, we represent that Header Confidentiality Policy as a function hcp
:¶
hcp(name, val_in) → val_out
: this function takes a non-structural Header Field identified by name
with initial value val_in
as arguments, and returns a replacement header value val_out
.
If val_out
is the special value null
, it means that the Header Field in question should be removed from the set of Header Fields visible outside the Cryptographic Envelope.¶
In the pseudocode descriptions of various choices of HCP in this document, any comparison with the name
input is done case-insensitively.
This is appropriate for Header Field names, as described in [RFC5322].¶
Note that hcp
is only applied to non-structural Header Fields.
When composing a message, Structural Header Fields are dealt with separately, as described in Section 2.5.6 and Section 2.5.7.¶
As an example, an MUA that obscures the Subject
Header Field by replacing it with the literal string "[...]
", hides all Cc'ed recipients, and does not offer confidentiality to any other Header Fields would be represented as (in pseudocode):¶
hcp_example_hide_cc(name, val_in) → val_out: if lower(name) is 'subject': return '[...]' else if lower(name) is 'cc': return null else: return val_in¶
Note that such a policy is only needed when the end-to-end protections include encryption (confidentiality). No comparable policy is needed for other end-to-end cryptographic protections (integrity and authenticity), as they are simply uniformly applied so that all Header Fields known by the sender have these protections.¶
This asymmetry is an unfortunate consequence of complexities in message delivery systems, some of which may reject, drop, or delay messages where all Header Fields are removed from the top-level MIME object.¶
This document does not mandate any particular Header Confidentiality Policy, though it offers guidance for MUA implementers in selecting one in Section 2.6. Future documents may recommend or mandate such a policy for an MUA with specific needs. Such a recommendation might be motivated by descriptions of metadata-derived attacks, or stem from research about message deliverability, or describe new signalling mechanisms, but these topics are out of scope for this document.¶
For alignment with common practice as well as the ABNF in Section 2.5.3 for HP-Outer
, val_out
MUST be one of the following:¶
identical to val_in
, or¶
the special value null
(meaning that the Header Field will be removed from the outside of the message), or¶
a sequence of printable and whitespace (that is, space or tab) 7-bit clean ASCII characters (of course, non-ASCII text can be encoded as ASCII using the encoded-word
construct from [RFC2047])¶
The HCP can compute val_out
using any technique describable in pseudocode, such as copying a fixed string or invocations of other pseudocode functions.
If it alters the value, it MUST NOT include control or NUL characters in val_out
.
val_out
SHOULD match the expected ABNF for the Header Field identified by name
.¶
This document defines a new Header Field, HP-Outer
.
HP-Outer
is used for conveying the effect of sender's Header Confidentiality Policy for an encrypted message.
It does so by embedding a copy within the Cryptographic Envelope of every non-structural Header Field that the sender put outside the Cryptographic Envelope.
This Header Field enables the MUA receiving the encrypted message to reliably identify whether the sending MUA intended to make a Header Field confidential (see Section 6.3).¶
An implementation that composes encrypted e-mail MUST include a copy of all non-structural Header Fields deliberately exposed to the outside of the Cryptographic Envelope using a series of HP-Outer
Header Fields within the Cryptographic Payload.
These HP-Outer
MIME Header Fields should only ever appear directly within the Header Section of the Cryptographic Payload of a Cryptographic Envelope offering confidentiality.
They MUST be ignored for the purposes of evaluating the message's Header Protection if they appear in other places.¶
Each instance of HP-Outer
contains a non-structural Header Field name and the value that this Header Field was set in the outer (unprotected) Header Section.
The HP-Outer
Header Field can appear multiple times in the Header Section of a Cryptographic Payload.¶
If a non-structural Header Field name A doesn't appear in an HP-Outer
Header Field value, then the sender is effectively asserting it was not set on the outside of the message's Cryptographic Envelope by the original message sender at the time the message was injected into the mail system.¶
The syntax of this Header Field is defined using the following ABNF [RFC5234], where field-name
, WSP
, VCHAR
, and FWS
are defined in [RFC5322]:¶
hp-outer = "HP-Outer:" [FWS] field-name ": " hp-outer-value CRLF hp-outer-value = (*([FWS] VCHAR) *WSP)¶
Note that hp-outer-value
is the same as unstructured
from [RFC5322], but without the obsolete obs-unstructured
option.¶
When a message is encrypted and it uses Header Protection, an MUA may need to extract a list of protected Header Fields (names and values), as well as a list of Header Fields that were added by the original message sender in unprotected form to the outside of the message's Cryptographic Envelope.¶
The following algorithm takes an reference message refmsg
as input, which is encrypted with Header Protection as described in this document (that is, the Cryptographic Envelope includes a Cryptographic Layer that provides encryption, and the hp
parameter for the Content-Type
Header Field of the Cryptographic Payload is cipher
).
It produces as output a pair of lists of (h,v)
Header Fields.¶
When refmsg
uses the Injected Headers scheme (that is, when there is no hp-scheme
parameter for the Content-Type
Header Field of the Cryptographic Payload):¶
Let refheaders
be the list of (h,v)
protected Header Fields found in the root of the Cryptographic Payload¶
When refmsg
uses the Wrapped Message scheme (that is, when the hp-scheme
parameter for the Content-Type
Header Field of the top-level message/rfc822
Cryptographic Payload is wrapped
):¶
Let refheaders
be the list of (h,v)
protected Header Fields found in the immediate child of the root of the Cryptographic Payload (recall that the root is a message/rfc822
)¶
Let refouter
be an empty list of Header Field names and values¶
Let refprotected
be an empty list of Header Field names and values¶
For each (h,v)
in refheaders
:¶
Return refouter
, refprotected
¶
Note that this algorithm is independent of the unprotected Header Fields.
It derives its output only from the normal Header Fields and the HP-Outer
Header Fields, both contained inside the Cryptographic Payload.¶
Some e-mail messages are written in response to another message. For example, the user of an MUA viewing any given message might take an action like "Reply", "Reply All", "Forward", or some comparable action to start the composition of a new message. The new message created this way effectively references the original message that was viewed at the time.¶
When the referenced message was itself encrypted with Header Protection, and some of its Header Fields had been obscured or removed, the replying MUA needs to make sure that the new message does not leak previously confidential header material. This section describes a method to produce a list of Header Fields that should be obscured or removed in the new message even if the sender's choice of Header Confidentiality Policy wouldn't normally remove or obscure the Header Field in question.¶
It takes two items as input:¶
A single referenced message refmsg
, and¶
A built-in MUA function respond
associated with the user's action.
respond
takes as input a list of headers from a referenced message and generates a list of initial candidate message Header Field names and values that are used to populate the message composition interface.
Something like this function already exists in most MUAs, though it may differ across responsive actions.
For example, the respond
function that implements "Reply All" is likely to be a different from the respond
that implements "Reply".¶
As output, we produce an ephemeral single-use Header Confidentiality Policy, specific to this kind of response to this specific message.¶
If refmsg
is not encrypted with Header Protection:¶
Return hcp_no_confidentiality
(there is no header confidentiality in the reference message that needs protection)¶
Extract refouter
, refprotected
from refmsg
as described in Section 2.5.4¶
Let genprotected
be a list of (h,v)
pairs generated by respond(refprotected)
¶
Let genouter
be a list of (h,v)
pairs generated by respond(refouter)
¶
For each (h,v)
in genprotected
:¶
Let confmap
be a mapping from a Header Field name and value (h,v)
to either a string or the special value null
(this mapping is initially empty)¶
For each (h,v)
remaining in genprotected
:¶
Return a new HCP from confmap
that tests whether (name,val_in)
are in confmap
; if so, return confmap[(name,val_in)]
; otherwise, return val_in
¶
Note that the key idea here is to reuse the MUA's existing respond
function.
The algorithm simulates how the MUA would pre-populate a reply to two traditional messages whose Header Fields have the values refouter
and refprotected
respectively (independent of any cryptographic protections).
Then it uses the difference to derive a one-time HCP.
This HCP takes into account both the referenced message's sender's preferences and the derivations that can happen to Header Field values when responding.
Note that while some of these derivations are straight forward (e.g., In-Reply-To
is usually derived from Message-ID
), others are non-trivial.
For example, From
may be derived from To
, Cc
, or from the MUA's local address preference (especially when the MUA received the referenced message via Bcc
).
Similarly, To
may be derived from To
, From
, and/or Cc
depending on the MUA implementation and depending on whether the user clicked "Reply", "Reply All", "Forward", or any other action that generates a response to a message.
Reusing the MUA's existing respond
function incorporates these nuances without requiring any extra configuration choices or additional maintenance burden.¶
To compose a message using "Injected Headers" Header Protection, the composing MUA uses the following inputs:¶
All the inputs described in Section 2.5.1¶
hcp
: a Header Confidentiality Policy, as defined in Section 2.5.2¶
response
: if the new message is a response to another message (e.g., "Reply", "Reply All", "Forward", etc), the MUA function corresponding to the user's action (see Section 2.5.5), otherwise null
¶
refmsg
: if the new message is a response to another message, the message being responded to, otherwise null
¶
legacy
: a boolean value, indicating whether any recipient of the message is believed to have a Legacy MUA.
If all recipients are known to implement this draft, legacy
should be set to false
.
(How an MUA determines the value of legacy
is out of scope for this document; an initial implementation can simply set it to true
)¶
To enable visibility of User-Facing but now removed/obscured Header Fields for decryption-capable Legacy MUAs, the Header Fields are included as a decorative Legacy Display Element in specially marked parts of the message (see Section 2.1).
This document recommends two mechanisms for such a decorative adjustment: one for a text/html
Main Body Part of the e-mail message, and one for a text/plain
Main Body Part.
This document does not recommend adding a Legacy Display Element to any other part.¶
Please see Section 7.1 of [I-D.ietf-lamps-e2e-mail-guidance] for guidance on identifying the parts of a message that are a Main Body Part.¶
The algorithm proceeds as follows:¶
Let newbody
be a copy of origbody
¶
If crypto
contains encryption, and legacy
is true
:¶
Create ldlist
, an empty list of (header, value)
pairs¶
For each Header Field name and value (h,v)
in origheaders
:¶
If h
is User-Facing (see Section 1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]):¶
If ldlist
is not empty:¶
Identify each leaf MIME part of newbody
that represents the "main body" of the message.¶
For each "Main Body Part" bodypart
of type text/plain
or text/html
:¶
Adjust bodypart
by inserting a Legacy Display Element header list ldlist
into its content, and adding a Content-Type
parameter hp-legacy-display
with value 1
(see Section 2.5.6.1 for text/plain
and Section 2.5.6.2 for text/html
)¶
For each Header Field name and value (h,v)
in origheaders
:¶
Add Header Field h
to MIME part newbody
with value v
¶
If crypto
does not contain encryption:¶
Else (if crypto
contains encryption):¶
Set the hp
parameter on the Content-Type
of MIME part newbody
to cipher
¶
If refmsg
is not null
, response
is not null
, and refmsg
itself is encrypted with header protection:¶
Let response_hcp
be a single-use HCP derived from response
and refmsg
(see Section 2.5.5)¶
Else (if this is not a response to an encrypted, header-protected message):¶
Set response_hcp
to hcp_no_confidentiality
¶
Create new empty list of Header Field names and values newheaders
¶
For each Header Field name and value (h,v)
in origheaders
:¶
For each Header Field name and value (h,v)
in newheaders
:¶
Apply crypto
to MIME part newbody
, producing MIME tree output
¶
For each Header Field name and value (h,v)
in newheaders
:¶
Add Header Field h
to output
with value v
¶
Return output
¶
Note that both new parameters (hcp
and legacy
) are effectively ignored if crypto
does not contain encryption.
This is by design, because they are irrelevant for signed-only cryptographic protections.¶
For a list of obscured and removed User-Facing Header Fields represented as (header, value)
pairs, concatenate them as a set of lines, with one newline at the end of each pair.
Add an additional trailing newline after the resultant text, and prepend the entire list to the body of the text/plain
part.¶
The MUA MUST also add a Content-Type
parameter of hp-legacy-display
with value 1
to the MIME part to indicate that a Legacy Display Element was added.¶
For example, if the list of obscured Header Fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/plain
Main Body Part that originally looked like this:¶
Content-Type: text/plain; charset=UTF-8 I think we should skip the meeting.¶
Would become:¶
Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1 Subject: Thursday's meeting Cc: alice@example.net I think we should skip the meeting.¶
Note that the Legacy Display Element (the lines beginning with Subject:
and Cc:
) are part of the body of the MIME part in question.¶
This example assumes that the Main Body Part in question is not the root of the Cryptographic Payload.
For instance, it could be a leaf of a multipart/alternative
Cryptographic Payload.
This is why no additional Header Fields have been injected into the MIME part in this example.¶
Adding a Legacy Display Element to a text/html
part is similar to how it is added to a text/plain
part (see Section 2.5.6.1).
Instead of adding the obscured or removed User-Facing Header Fields to a block of text delimited by a blank line, the composing MUA injects them in an HTML <div>
element annotated with a class
attribute of header-protection-legacy-display
.¶
The content and formatting of this decorative <div>
have no strict requirements, but they MUST represent all the obscured and removed User-Facing Header Fields in a readable fashion.
A simple approach is to assemble the text in the same way as Section 2.5.6.1, wrap it in a verbatim <pre>
element, and put that element in the annotated <div>
.¶
The annotated <div>
should be placed as close to the start of the <body>
as possible, where it will be visible when viewed with a standard HTML renderer.¶
The MUA MUST also add a Content-Type
parameter of hp-legacy-display
with value 1
to the MIME part to indicate that a Legacy Display Element was added.¶
For example, if the list of obscured Header Fields was [("Cc", "alice@example.net"), ("Subject", "Thursday's meeting")]
, then a text/html
Main Body Part that originally looked like this:¶
Content-Type: text/html; charset=UTF-8 <html><head><title></title></head><body> <p>I think we should skip the meeting.</p> </body></html>¶
Would become:¶
Content-Type: text/html; charset=UTF-8; hp-legacy-display=1 <html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Thursday's meeting Cc: alice@example.net</pre></div> <p>I think we should skip the meeting.</p> </body></html>¶
This example assumes that the Main Body Part in question is not the root of the Cryptographic Payload.
For instance, it could be a leaf of a multipart/alternative
Cryptographic Payload.
This is why no additional Header Fields have been injected into the MIME part in this example.¶
A composing MUA MAY insert the Legacy Display Element anywhere reasonable within the message as long as it prioritizes visibility for the reader using a Legacy decryption-capable MUA. This decision may take into account special message-specific HTML formatting expectations if the MUA is aware of them. However, some MUAs may not have any special insight into the user's preferred HTML formatting, and still want to insert a Legacy Display Element. This section offers a non-normative, simple, and minimal step-by-step approach for a composing MUA that has no other information or preferences to fall back on.¶
The process below assumes that the MUA already has the full HTML object that it intends to send, including all of the text supplied by the user.¶
Assemble the text exactly as specified for text/plain
(see Section 2.5.6.1).¶
Wrap that text in a verbatim <pre>
element.¶
Wrap that <pre>
element in a <div>
element annotated with the class header-protection-legacy-display
.¶
Find the <body>
element of the full HTML object.¶
Insert the <div>
element as the first child of the <body>
element.¶
Some messages may contain a text/plain
or text/html
subpart that is not a Main Body Part.
For example, an e-mail message might contain an attached text file or a downloaded webpage.
Attached documents need to be preserved as intended in the transmission, without modification.¶
The composing MUA MUST NOT add a Legacy Display Element to any part of the message that is not a Main Body Part.
In particular, if a part is annotated with Content-Disposition: attachment
, or if it does not descend via the first child of any of its multipart/mixed
or multipart/related
ancestors, it is not a Main Body Part, and MUST NOT be modified.¶
See Section 7.1 of [I-D.ietf-lamps-e2e-mail-guidance] for more guidance about common ways to distinguish Main Body Parts from other MIME parts in a message.¶
The purpose of injecting a Legacy Display Element into each Main Body MIME part is to enable rendering of otherwise obscured Header Fields in Legacy MUAs that are capable of message decryption, but don't know how to follow the rest of the guidance in this document.¶
The authors are unaware of any Legacy MUA that would render any MIME part type other than text/plain
and text/html
as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display Element to any MIME part with any other Content-Type
.¶
To compose a message using "Wrapped Message" Header Protection, the composing MUA uses the following inputs:¶
All the inputs described in Section 2.5.1¶
hcp
: a Header Confidentiality Policy, as defined in Section 2.5.2¶
response
: if the new message is a response to another message (e.g., "Reply", "Reply All", "Forward", etc), the MUA function corresponding to the user's action (see Section 2.5.5), otherwise null
¶
refmsg
: if the new message is a response to another message, the message being responded to, otherwise null
¶
The algorithm proceeds as follows:¶
Let newbody
be a copy of origbody
¶
For each Header Field name and value (h,v)
in origheaders
:¶
Add Header Field h
to MIME part newbody
with value v
¶
If crypto
does not contain encryption:¶
Let newheaders
be a copy of origheaders
¶
Else (if crypto
contains encryption):¶
If refmsg
is not null
, response
is not null
, and refmsg
itself is encrypted with header protection:¶
Let response_hcp
be a single-use HCP derived from response
and refmsg
(see Section 2.5.5)¶
Else (if this is not a response to an encrypted, header-protected message):¶
Set response_hcp
to hcp_no_confidentiality
¶
Create new empty list of Header Field names and values newheaders
¶
For each Header Field name and value (h,v)
in origheaders
:¶
For each Header Field name and value (h,v)
in newheaders
:¶
If any of the Header Fields in MIME part newbody
, including Header Fields in the nested internal MIME structure, contain any 8-bit UTF-8 characters (see Section 3.7 of [RFC6532]):¶
Let payload
be a new MIME part with one Header Field: Content-Type: message/global
¶
Else:¶
Let payload
be a new MIME part with one Header Field: Content-Type: message/rfc822
¶
If crypto
contains encryption:¶
Add a parameter hp="cipher"
to the Content-Type
Header Field of payload
¶
Else (if crypto
does not contain encryption):¶
Add a parameter hp="clear"
to the Content-Type
Header Field of payload
¶
Add a parameter hp-scheme="wrapped"
to the Content-Type
Header Field of payload
¶
Set the body of payload
to newbody
.¶
Add a Content-Disposition
Header Field to MIME part payload
with value inline
¶
Apply crypto
to MIME part payload
, producing MIME tree output
¶
For each Header Field name and value (h,v)
in newheaders
:¶
Add Header Field h
to output
with value v
¶
Return output
¶
Note that the Header Confidentiality Policy hcp
parameter is effectively ignored if crypto
does not contain encryption.
This is by design, because a signed-only message cannot provide confidentiality.¶
An MUA MUST have a default Header Confidentiality Policy that offers at least the protections provided by hcp_minimal
as described in Section 2.6.1.
Local policy and configuration may alter this default, but the MUA SHOULD NOT require the user to select an HCP.¶
hcp_minimal
provides confidentiality for the Subject
Header Field by replacing it with the literal string "[...]
".
This is a sensible minimal default because most users treat the Subject of a message the same way that they treat the body, and they are surprised to find that the Subject of an encrypted message is visible.¶
The most conservative recommended Header Confidentiality Policy only protects the Subject
Header Field:¶
hcp_minimal(name, val_in) → val_out: if lower(name) is 'subject': return '[...]' else: return val_in¶
hcp_minimal
is the recommended default HCP for a new implementation, as it provides meaningful confidentiality protections and is unlikely to cause deliverability or usability problems.¶
Alternately, a more ambitious (and therefore more privacy-preserving) Header Confidentiality Policy only leaks a handful of fields whose absence is known to increase rates of delivery failure, and simultaneously obscures the Message-ID
behind a random new one:¶
hcp_strong(name, val_in) → val_out: if lower(name) in ['from', 'to', 'cc', 'date']: return val_in else if lower(name) is 'subject': return '[...]' else if lower(name) is 'message-id': return generate_new_message_id() else: return null¶
The function generate_new_message_id()
represents whatever process the MUA typically uses to generate a Message-ID
for a new outbound message.¶
hcp_strong
is known to cause usability problems with message threading for many Legacy MUAs, and is not recommended as a default HCP for new implementations.¶
Legacy MUAs can be conceptualized as offering a "No Header Confidentiality" Policy, which offers no confidentiality protection to any Header Field:¶
hcp_no_confidentiality(name, val_in) → val_out: return val_in¶
A conformant MUA that is not modified by local policy or configuration MUST NOT use hcp_no_confidentiality
by default.¶
An MUA MAY offer even more ambitious confidentiality for Header Fields of an encrypted message than described in Section 2.6.2.
For example, it might implement an HCP that obscures the From
Header Field, removes the Cc
Header Field, or ensures Date
is represented in UTC
(obscuring the local time zone).¶
The authors of this document hope that implementers with deployment experience will document their chosen Header Confidentiality Policy and the rationale behind their choice.¶
This document defines hcp_no_confidentiality
, hcp_minimal
, and hcp_strong
as a way to compare and contrast different possible behavioral choices for a composing MUA.
An example hypothetical HCP, hcp_example_hide_cc
is included in Section 2.5.2.
While the HCP is not strictly a protocol element, this document creates a registry of named Header Confidentiality Policies for ease of communication.¶
There is no formal syntax specified for the Header Confidentiality Policy, but any attempt to specify an HCP for inclusion in the registry needs to provide:¶
a stable reference document clearly indicating the distinct name for the proposed HCP¶
pseudocode that other implementers can clearly and unambiguously interpret¶
a clear explanation of why this HCP is different from all other registered HCPs¶
any relevant considerations related to deployment of the HCP (for example, known or expected deliverability, rendering, or privacy challenges and possible mitigations)¶
When the proposed HCP produces any non-null
output for a given Header Field name, val_out
SHOULD match the expected ABNF for that Header Field.
If the proposed HCP does not match the expected ABNF for that Header Field, the documentation should explicitly identify the relevant circumstances and provide a justification for the deviation.¶
An entry should not be marked as "Recommended" unless it has been shown to offer confidentiality or privacy improvements over the status quo and have minimal or mitigatable negative impact on messages to which it is applied, considering factors such as message deliverability and security.
Only one entry in the table (hcp_minimal
) is initially marked as "Recommended".
In the future, more than one entry may be marked as "Recommended".¶
An MUA that receives a cryptographically protected e-mail will render it for the user.¶
The receiving MUA will render the message body, a selected subset of Header Fields, and (as described in Section 3 of [I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the cryptographic properties of the message.¶
Most MUAs only render a subset of Header Fields by default.
For example, most MUAs render From
, To
, Cc
, Date
, and Subject
to the user, but few render Message-Id
or Received
.¶
An MUA that knows how to handle a message with Header Protection makes the following three changes to its behavior when rendering a message:¶
If the MUA detects that an incoming message has protected Header Fields:¶
For a Header Field that is present in the protected Header Section, the MUA MUST render that value, and ignore any unprotected counterparts that may be present.¶
For a Header Field that is present only in the unprotected Header Section, the MUA SHOULD NOT render that value.
If it does render the value, the MUA SHOULD indicate that the rendered value is unprotected
.
For an exception to this, see Section 2.7.10 for a discussion of some specific Header Fields that are known to be added in transit, and therefore are not expected to have end-to-end cryptographic protections.¶
The MUA SHOULD include information in the message's Cryptographic Summary to indicate the types of protection that applied to each rendered Header Field (if any).¶
When replying to a message with confidential Header Fields, the replying MUA avoids leaking into the cleartext of the reply any Header Fields which were confidential in the original. It does this even if its own Header Confidentiality Policy would not have treated those Header Fields as confidential. See Section 2.7.8 for more details.¶
Note that an MUA that handles a message with Header Protection does not need to render any new Header Fields that it did not render before.¶
An incoming message can be identified as having Header Protection based on one of two signals:¶
The Cryptographic Payload has Content-Type: message/rfc822
or Content-Type: message/global
and the parameter hp
has a value of clear
or cipher
, and the hp-scheme
has a value of wrapped
.
See Section 2.7.4 for rendering guidance.¶
The Cryptographic Payload has some other Content-Type
and it has parameter hp
set to clear
or cipher
.
See Section 2.7.3 for rendering guidance.¶
Messages of both types exist in the wild, and a compliant MUA MUST be able to handle them both. They provide the same semantics and the same meaning.¶
Regardless of whether a cryptographically protected message has protected Header Fields, the Cryptographic Summary of the message should be modified to indicate what protections the Header Fields have. This field-by-field status is complex and isn't necessarily intended to be presented in full to the user. Rather, it represents the state of the message internally within the MUA, and may be used to influence behavior like replying to the message (see Section 2.7.8.1).¶
Each Header Field individually has exactly one of the following protection states:¶
unprotected
(has no Header Protection)¶
signed-only
(bound into the same validated signature as the enclosing message, but also visible in transit)¶
encrypted-only
(only appears within the Cryptographic Payload; the corresponding external Header Field was either removed or obscured)¶
signed-and-encrypted
(same as encrypted-only, but additionally is under a validated signature)¶
If the message does not have Header Protection (as determined by Section 2.7.1), then all of the Header Fields are by definition unprotected
.¶
If the message has Header Protection, an MUA SHOULD use the following algorithm to compute the protection state of a protected Header Field (h,v)
(i.e., an element of refprotected
from Section 2.5.4):¶
Let ct
be the Content-Type
of the root of the Cryptographic Payload.¶
Let refouter
be the list of unprotected Header Fields (as computed by Section 2.5.4).¶
Let is_sig_valid
be false
¶
If the message is signed:¶
Let is_sig_valid
be the result of validating the signature¶
If the message is encrypted, and if ct
has a parameter hp=cipher
, and if (h,v)
is not in refouter
:¶
Return signed-and-encrypted
if is_sig_valid
otherwise encrypted-only
¶
Return signed-only
if is_sig_valid
otherwise unprotected
¶
Note that:¶
This algorithm is independent of the unprotected Header Fields.
It derives the protection state only from (h,v)
and the set of HP-Outer
Header Fields, both of which are inside the Cryptographic Envelope.¶
If the signature fails validation, the MUA lowers the affected state to unprotected
or encrypted-only
without warning the user, as specified by Section 3.1 of [I-D.ietf-lamps-e2e-mail-guidance].¶
Data from signed-and-encrypted
and encrypted-only
Header Fields may still not be fully private (see Section 6.2).¶
Encryption may have been added in transit to an originally signed-only message. Thus only consider Header Fields to be confidential if the sender indicates it with the hp=cipher
parameter.¶
The protection state of a Header Field may be weaker than that of the message body.
For example, a message body can be signed-and-encrypted
, but a Header Field that is copied unmodified to the unprotected Header Section is signed-only
.¶
If the message has Header Protection, Header Fields that are not in refprotected
(e.g., because they were added in transit), are unprotected
.¶
Rendering the cryptographic status of each Header Field is likely to be complex and messy --- users may not understand it. It is beyond the scope of this document to suggest any specific graphical affordances or user experience. Future work should include examples of successful rendering of this information.¶
When the Cryptographic Payload does not have a Content-Type
of message/rfc822
or message/global
, and the parameter hp
is set to clear
or cipher
, the values of the protected Header Fields are drawn from the Header Fields of the Cryptographic Payload, and the body that is rendered is the Cryptographic Payload itself.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
A └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] C ├─╴text/plain D └─╴text/html¶
The message body should be rendered the same way as this message:¶
B └┬╴multipart/alternative C ├─╴text/plain D └─╴text/html¶
The MUA should render Header Fields taken from part B
.¶
Its Cryptographic Summary should indicate that the message was signed and all rendered Header Fields were included in the signature.¶
Because this message is signed-only, none of its parts will have a Legacy Display Element.¶
The MUA should ignore Header Fields from part A
for the purposes of rendering.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
E └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) F └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) G └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] H ├─╴text/plain I └─╴text/html¶
The message body should be rendered the same way as this message:¶
G └┬╴multipart/alternative H ├─╴text/plain I └─╴text/html¶
It should render Header Fields taken from part G
.¶
Its Cryptographic Summary should indicate that the message is signed-and-encrypted
.¶
When rendering the Cryptographic Status of a Header Field and when composing a reply, each Header Field found in G
should be considered against all HP-Outer
Header Fields found in G
.
If an HP-Outer
Header Field is found that matches both the name and value, the Header Field's Cryptographic Status is just signed-only
, even though the message itself is signed-and-encrypted
.
If no matching HP-Outer
Header Field is found, the Header Field's Cryptographic Status is signed-and-encrypted
, like the rest of the message.¶
If any of the User-Facing Header Fields are removed or obscured, the composer of this message may have placed Legacy Display Elements in parts H and I.¶
The MUA should ignore Header Fields from part E
for the purposes of rendering.¶
As described in Section 2.1, a message with cryptographic confidentiality protection MAY include Legacy Display Elements for backward-compatibility with Legacy MUAs. These Legacy Display Elements are strictly decorative, unambiguously identifiable, and will be discarded by compliant implementations.¶
The receiving MUA MUST avoid rendering the identified Legacy Display Elements to the user at all, since it is aware of Header Protection and can render the actual protected Header Fields.¶
If a text/html
or text/plain
part within the Cryptographic Envelope is identified as containing Legacy Display Elements, those elements MUST be hidden when rendering and MUST be dropped when generating a draft reply or inline forwarded message.
Whenever a Message or MIME subtree is exported, downloaded, or otherwise further processed, if there is no need to retain a valid cryptographic signature, the implementer MAY drop the Legacy Display Elements.¶
A receiving MUA acting on a message that contains an encrypting Cryptographic Layer identifies a MIME subpart within the Cryptographic Payload as containing Legacy Display Elements based on the Content-Type of the subpart. The subpart's Content-Type:¶
contains a parameter hp-legacy-display
with value set to 1
, and¶
is either text/html
(see Section 2.7.3.3.3) or text/plain
(see Section 2.7.3.3.2).¶
Note that the term "subpart" above is used in the general sense: if the Cryptographic Payload is a single part, that part itself may contain a Legacy Display Element if it is marked with the hp-legacy-display=1
parameter.¶
If a text/plain
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
Discard the leading lines of the body of the part up to and including the first entirely blank line.¶
Note that implementing this strategy is dependent on the charset used by the MIME part.¶
See Appendix D.1 for an example.¶
If a text/html
part within the Cryptographic Payload has the Content-Type parameter hp-legacy-display="1"
, it should be processed before rendering in the following fashion:¶
If any element of the HTML <body>
is a <div>
with class
attribute header-protection-legacy-display
, that entire element should be omitted.¶
This cleanup could be done, for example, as a custom rule in the MUA's HTML sanitizer, if one exists. Another implementation strategy for an HTML-capable MUA would be to add an entry to the [CSS] stylesheet for such a part:¶
body div.header-protection-legacy-display { display: none; }¶
When the Cryptographic Payload has Content-Type
of message/rfc822
or message/global
, and the parameter hp
is set to clear
or cipher
, and the parameter hp-scheme
is set to wrapped
, the values of the protected Header Fields are drawn from the Header Fields of the Cryptographic Payload, and the body that is rendered is the body of the Cryptographic Payload.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
J └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) K └┬╴message/rfc822 [Cryptographic Payload] L └┬╴multipart/alternative [Rendered Body] M ├─╴text/plain N └─╴text/html¶
The message body should be rendered the same way as this message:¶
L └┬╴multipart/alternative M ├─╴text/plain N └─╴text/html¶
It should render Header Fields taken from part K
.¶
Its Cryptographic Summary should indicate that the message was signed and all rendered Header Fields were included in the signature.¶
The MUA should ignore Header Fields from part J
for the purposes of rendering.¶
Consider a message with this structure, where the MUA is able to validate the cryptographic signature:¶
O └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) P └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) Q └┬╴message/rfc822 [Cryptographic Payload] R └┬╴multipart/alternative [Rendered Body] S ├─╴text/plain T └─╴text/html¶
The message body should be rendered the same way as this message:¶
R └┬╴multipart/alternative S ├─╴text/plain T └─╴text/html¶
It should render Header Fields taken from part Q
.¶
Its Cryptographic Summary should indicate that the message is signed-and-encrypted
.¶
When rendering the Cryptographic Status of a Header Field and when composing a reply, each Header Field found in Q
should be considered against all HP-Outer
Header Fields found in Q
.
If an HP-Outer
Header Field is found that matches both the name and value, the Header Field's Cryptographic Status is just signed-only
, even though the message itself is signed-and-encrypted
.
If no matching HP-Outer
Header Field is found, the Header Field's Cryptographic Status is signed-and-encrypted
, like the rest of the message.¶
The MUA should ignore Header Fields from part O
for the purposes of rendering.¶
Some automated systems have a control channel that is operated by e-mail. For example, an incoming e-mail message could subscribe someone to a mailing list, initiate the purchase of a specific product, approve another message for redistribution, or adjust the state of some shared object.¶
To the extent that such a system depends on end-to-end cryptographic guarantees about the e-mail control message, Header Protection as described in this document should improve the system's security. This section provides some specific guidance for systems that use e-mail messages as a control channel that want to benefit from these security improvements.¶
Consider the situation where an e-mail-based control channel depends on the message's cryptographic signature and the action taken depends on some Header Field of the message.¶
In this case, the automated system MUST rely on information from the Header Field that is protected by the mechanism described in this document. It MUST NOT rely on any Header Field found outside the Cryptographic Payload.¶
For example, consider an administrative interface for a mailing list manager that only accepts control messages that are signed by one of its administrators.
When an inbound message for the list arrives, it is queued (waiting for administrative approval) and the system generates and listens for two distinct e-mail addresses related to the queued message -- one that approves the message, and one that rejects it.
If an administrator sends a signed control message to the approval address, the mailing list verifies that the protected To
Header Field of the signed control message contains the approval address before approving the queued message for redistribution.
If the protected To
Header Field does not contain that address, or there is no protected To
Header Field, then the mailing list logs or reports the error and does not act on that control message.¶
Consider the situation where an e-mail-based control channel expects to receive an end-to-end encrypted message -- for example, where the control messages need confidentiality guarantees -- and where the action taken depends on the contents of some MIME part within the message body.¶
In this case, the automated system that decrypts the incoming messages and scans the relevant MIME part MUST identify when the MIME part contains a Legacy Display Element (see Section 2.7.3.3.1), and it MUST parse the relevant MIME part with the Legacy Display Element removed.¶
For example, consider an administrative interface of a confidential issue tracking software.
An authorized user can confidentially adjust the status of a tracked issue by a specially formatted first line of the message body (for example, severity #183 serious
).
When the user's MUA encrypts a plain text control message to this issue tracker, depending on the MUA's HCP and its choice of legacy
value, it may add a Legacy Display Element.
If it does so, then the first line of the message body will contain a decorative copy of the confidential Subject
Header Field.
The issue tracking software decrypts the incoming control message, identifies that there is a Legacy Display Element in the part (see Section 2.7.3.3.1), strips the lines comprising the Legacy Display Element (including the first blank line), and only then parses the remaining top line to look for the expected special formatting.¶
Note that advanced users of an MUA may need access to the original message, for example to troubleshoot problems with the rendering MUA itself, or problems with the SMTP transport path taken by the message.¶
An MUA that applies these rendering guidelines SHOULD ensure that the full original source of the message as it was received remains available to such a user for debugging and troubleshooting.¶
If a troubleshooting scenario demands information about the cryptographically protected values of Header Fields, and the message is encrypted, the debugging interface SHOULD also provide a "source" view of the Cryptographic Payload itself, alongside the full original source of the message as received.¶
Other MUAs may have generated different structures of messages that aim to offer end-to-end cryptographic protections that include Header Protection. This document is not normative for those schemes, and it is NOT RECOMMENDED to generate these other schemes, as they can either have structural flaws or simply render poorly on Legacy MUAs. A conformant MUA MAY attempt to infer Header Protection when rendering an existing message that appears to use some other scheme not documented here. Pointers to some known other schemes can be found in Appendix E.¶
When composing a reply to a message with Header Protection, the MUA is acting both as a receiving MUA and as a sending MUA. For encrypted messages, special guidance applies, because information can leak in at least two ways: leaking previously confidential Header Fields, and leaking the entire message by replying to the wrong party.¶
As noted in Section 5.4 of [I-D.ietf-lamps-e2e-mail-guidance], an MUA in this position MUST NOT leak previously encrypted content in the clear in a follow-up message. The same is true for protected Header Fields.¶
Values from any Header Field that was identified as either encrypted-only
or signed-and-encrypted
based on the steps outlined above MUST NOT be placed in cleartext output when generating a message.¶
In particular, if Subject
was encrypted, and it is copied into the draft encrypted reply, the replying MUA MUST obscure the unprotected (cleartext) Subject
Header Field as described above.¶
When crafting the Header Fields for a reply message, the composing MUA SHOULD make use of the HP-Outer
Header Fields from within the Cryptographic Envelope of the reference message to ensure that Header Fields derived from the reference message do not leak in the reply.
See Section 2.5.5 for an explicit algorithm to handle this cleanly.¶
Consider a Header Field in a reply message that is generated by derivation from a Header Field in the reference message.
For example, the To
Header Field is typically derived from the reference message's Reply-To
or From
Header Fields.
When generating the outer copy of the Header Field, the composing MUA first applies its own Header Confidentiality Policy.
If the Header Field's value is changed by the HCP, then it is applied to the outside header.
If the Header Field's value is unchanged, the composing MUA re-generates the Header Field using the Header Fields that had been on the outside of the original message at sending time.
These can be inferred from the HP-Outer
Header Fields located within the Cryptographic Payload of the referenced message.
If that value is itself different than the protected value, then it is applied to the outside header.
If the value is the same as the protected value, then it is simply copied to the outside header directly.
Whether it was changed or not, it is noted in the protected Header Section using HP-Outer
, as described in Section 2.5.3.¶
See Appendix C.2 for a simple worked example of this process.¶
When replying to a message, the Composing MUA typically decides who to send the reply to based on:¶
the Reply-To
, Mail-Followup-To
, or From
Header Fields¶
optionally, the other To
or Cc
Header Fields (if the user chose to "reply all")¶
When a message has Header Protection, the replying MUA MUST populate the destination fields of the draft message using the protected Header Fields, and ignore any unprotected Header Fields.¶
This mitigates against an attack where Mallory gets a copy of an encrypted message from Alice to Bob, and then replays the message to Bob with an additional Cc
to Mallory's own e-mail address in the message's outer (unprotected) Header Section.¶
If Bob knows Mallory's certificate already, and he replies to such a message without following the guidance in this section, it's likely that his MUA will encrypt the cleartext of the message directly to Mallory.¶
While From
, To
, Cc
, Subject
, and Date
are often explicitly rendered to the user, some Header Fields do affect message display, without being explicitly rendered.¶
For example, Message-Id
, References
, and In-Reply-To
Header Fields may collectively be used to place a message in a "thread" or series of messages.¶
In another example, Section 2.7.8.2 observes that the value of the Reply-To
field can influence the draft reply message.
So while the user may never see the Reply-To
Header Field directly, it is implicitly "rendered" when the user interacts with the message by replying to it.¶
An MUA that depends on any implicitly rendered Header Field in a message with Header Protection MUST use the value from the protected Header Field, and SHOULD NOT use any value found outside the cryptographic protection unless it is known to be a Header Field added in transit, as specified in Section 2.7.10.¶
Some Header Fields are legitimately added in transit and could not have been known to the sender at message composition time.¶
The most common of these Header Fields are Received
and DKIM-Signature
, neither of which are typically rendered, either explicitly or implicitly.¶
If a receiving MUA has specific knowledge about a given Header Field, including that:¶
the Header Field would not have been known to the original sender, and¶
the Header Field might be rendered explicitly or implicitly,¶
then the MUA MAY decide to operate on the value of that Header Field from the unprotected Header Section, even though the message has Header Protection.¶
The MUA MAY prefer to verify that the Header Fields in question have additional transit-derived cryptographic protections before rendering or acting on them.
For example, the MUA could verify whether these Header Fields are covered by an appropriate and valid ARC-Authentication-Results
(see [RFC8617]) or DKIM-Signature
(see [RFC6376]) Header Field.¶
Specific examples of user-meaningful Header Fields commonly added by transport agents appear below.¶
If the message arrives through a mailing list, the list manager itself may inject Header Fields (most have a List-
prefix) in the message:¶
For some MUAs, these Header Fields are implicitly rendered, by providing buttons for actions like "Subscribe", "View Archived Version", "Reply List", "List Info", etc.¶
An MUA that receives a message with Header Protection that contains these Header Fields in the unprotected section, and that has reason to believe the message is coming through a mailing list MAY decide to render them to the user (explicitly or implicitly) even though they are not protected.¶
An MUA might receive an apparently encrypted message that it cannot currently decrypt. For example, when an MUA does not have regular access to the secret key material needed for decryption, it cannot know the cryptographically protected Header Fields or even whether the message has any cryptographically protected Header Fields.¶
Such an undecrypted message will be rendered by the MUA as a message without any Header Protection. This means that the message summary may well change how it is rendered when the user is finally able to supply the secret key.¶
For example, the rendering of the Subject
Header Field in a mailbox summary might change from [...]
to the real message subject when the message is decrypted.
Or the message's placement in a message thread might change if, say, References
or In-Reply-To
have been removed or obscured (see Section 2.7.9).¶
Additionally, if the MUA does not retain access to the decrypting secret key, and it drops the decrypted form of a message, the message's rendering may revert to the encrypted form.
For example, if an MUA follows this behavior, the Subject
Header Field in a mailbox summary might change from the real message subject back to [...]
.
Or the message might be yanked out of its current thread if the MUA loses access to a removed References
or In-Reply-To
header.¶
These behaviors are likely to surprise the user. However, an MUA has several possible ways of reducing or avoiding all of these surprises, including:¶
Ensuring that the MUA always has access to decryption-capable secret key material.¶
Rendering undecrypted messages in a special quarantine view until the decryption-capable secret key material is available.¶
To reduce or avoid the surprises associated with a decrypted message with removed or obscured Header Fields becoming undecryptable, the MUA could also:¶
Securely cache metadata from a decrypted message's protected Header Fields so that its rendering doesn't change after the first decryption.¶
Securely store the session key associated with a decrypted message, so that attempts to read the message when the long-term secret key are unavailable can proceed using only the session key itself. See, for example, the discussion about stashing session keys in Section 9.1 of [I-D.ietf-lamps-e2e-mail-guidance].¶
This document is intended to offer tooling needed to improve the state of the e-mail ecosystem in a way that can be deployed without significant disruption. Some elements of this specification are present for transitional purposes, but would not exist if the system were designed from scratch.¶
This section describes these transitional mechanisms, as well as some suggestions for how they might eventually be phased out.¶
Any decorative Legacy Display Element added to an encrypted message that uses the Injected Header scheme is present strictly for enabling Header Field visibility (most importantly, the Subject Header Field) when the message is viewed with a decryption-capable Legacy MUA.¶
Eventually, the hope is that most decryption-capable MUAs will conform to this specification, and there will be no need for injection of Legacy Display Elements in the message body. A survey of widely used decryption-capable MUAs might be able to establish when most of them do support this specification.¶
At that point, a composing MUA could set the legacy
parameter described in Section 2.5.6 to false
by default or could even hard-code it to false
, yielding a much simpler message construction set.¶
Until that point, an end user might want to signal that their receiving MUAs are conformant to this document so that a peer composing a message to them can set legacy
to false
.
A signal indicating capability of handling messages with Header Protection might be placed in the user's cryptographic certificate, or in outbound messages.¶
This document does not attempt to define the syntax or semantics of such a signal.¶
This document defines a few different forms of Header Confidentiality Policy.
An MUA implementing an HCP for the first time SHOULD deploy hcp_minimal
as recommended in Section 2.6.
This HCP offers the most commonly expected protection (obscuring the Subject Header Field) without risking deliverability or rendering issues.¶
The HCPs proposed in this document are relatively conservative and still leak a significant amount of metadata for encrypted messages. This is largely done to ensure deliverability (see Section 1.4.2) and usability, as messages without some critical Header Fields are more likely to not reach their intended recipient.¶
In the future, some mail transport systems may accept and deliver messages with even less publicly visible metadata. Many MTA operators today would ask for additional guarantees about such a message to limit the risks associated with abusive or spammy mail.¶
This specification offers the HCP formalism itself as a way for MUA developers and MTA operators to describe their expectations around message deliverability. MUA developers can propose a more ambitious default HCP, and ask MTA operators (or simply test) whether their MTAs would be likely to deliver or reject encrypted mail with that HCP applied. Proponents of a more ambitious HCP should explicitly document the HCP and name it clearly and unambiguously to facilitate this kind of interoperability discussion.¶
Reaching widespread consensus around a more ambitious global default HCP is a challenging problem of coordinating many different actors. A piecemeal approach might be more feasible, where some signalling mechanism allows a message recipient, MTA operator, or third-party clearinghouse to announce what kinds of HCPs are likely to be deliverable for a given recipient. In such a situation, the default HCP for an MUA might involve consulting the signalled acceptable HCPs for all recipients, and combining them (along with a default for when no signal is present) in some way.¶
If such a signal were to reach widespread use, it could also be used to guide reasonable statistical default HCP choices for recipients with no signal.¶
This document does not attempt to define the syntax or semantics of such a signal.¶
At some point, when the majority of MUA clients that can generate cryptographically protected messages with Header Protection, it should be possible to deprecate any cryptographically protected message that does not have Header Protection.¶
For example, as noted in Section 4.1, it's possible for an MUA to render a signed-only
message that has no Header Protection the same as an unprotected
message.
And a signed-and-encrypted
message without Header Protection could likewise be marked as not fully protected.¶
These stricter rules could be adopted immediately for all messages. Or an MUA developer could roll them out immediately for any new message, but still treat an old message (based on the Date Header Field and cryptographic signature timestamp) more leniently.¶
A decision like this by any popular receiving MUA could drive adoption of this standard for sending MUAs.¶
This section describes concerns for MUAs that are interested in easy adoption of Header Protection by normal users.¶
While they are not protocol-level artifacts, these concerns motivate the protocol features described in this document.¶
See also the Usability commentary in Section 2 of [I-D.ietf-lamps-e2e-mail-guidance].¶
When rendering a message to the user, the ideal circumstance is to present a single cryptographic status for any given message. However, when message Header Fields are present, some message Header Fields do not have the same cryptographic protections as the main message.¶
Representing such a mixed set of protection statuses is very difficult to do in a way that a Ordinary User can understand. There are at least three scenarios that are likely to be common, and poorly understood:¶
A signed message with no Header Protection.¶
A signed-and-encrypted message with no Header Protection.¶
A signed-and-encrypted message with Header Protection as described in this document, where some User-Facing Header Fields have confidentiality but some do not.¶
An MUA should have a reasonable strategy for clearly communicating each of these scenarios to the user. For example, an MUA operating in an environment where it expects most cryptographically protected messages to have Header Protection could use the following rendering strategy:¶
When rendering a message with signed-only
cryptographic status but no Header Protection, an MUA may decline to indicate a positive security status overall, and only indicate the cryptographic status to a user in a message properties or diagnostic view.
That is, the message may appear identical to an unsigned message except if a user verifies the properties through a menu option.¶
When rendering a message with signed-and-encrypted
or encrypted-only
cryptographic status but no Header Protection, overlay a warning flag on the typical cryptographic status indicator.
That is, if a typical signed-and-encrypted
message displays a lock icon, display a lock icon with a warning sign (e.g., an exclamation point in a triangle) overlaid.
See, for example, the graphics in [chrome-indicators].¶
When rendering a message with signed-and-encrypted
or encrypted-only
cryptographic status, with Header Protection, but where the Subject Header Field has not been removed or obscured, place a warning sign on the Subject line.¶
Other simple rendering strategies could also be reasonable.¶
This document defines the abstraction of a Header Confidentiality Policy object for the sake of communication between implementers and deployments.¶
Most e-mail users are unlikely to understand the tradeoffs between different policies. In particular, the potential negative side effects (e.g., poor deliverability) may not be easily attributable by a normal user to a particular HCP.¶
Therefore, MUA implementers should be conservative in their choice of default HCP, and should not require the Ordinary User to make an incomprehensible choice that could cause unfixable, undiagnosable problems.
The safest option is for the MUA developer to select a known, stable HCP (this document recommends hcp_minimal
in Section 2.6) on the user's behalf.
An MUA should not expose the Ordinary User to a configuration option where they are expected to manually select (let alone define) an HCP.¶
This document describes two Header Protection schemes: Injected Headers (Section 2.1) and Wrapped Messages (Section 2.2).¶
These distinct schemes are described for the sake of implementers who may have to deal with messages found in the wild, but their intended semantics are identical. They represent different tradeoffs in terms of rendering and user experience on the recipient's side, which an Ordinary User writing a message is not prepared to select.¶
When composing a message with cryptographic protections, the Ordinary User should not be confronted with any choices about which Header Protection scheme to use. Rather, the MUA developer should use a single scheme for all outbound cryptographically protected messages. This document recommends the Injected Headers scheme (see Section 2).¶
This document describes a mechanism for improving the security of cryptographically protected e-mail messages. Following the guidance in this document should improve security for users of these technologies by more directly aligning the underlying messages with user expectations about confidentiality, authenticity, and integrity.¶
However, many existing messages with cryptographic protections do not employ these mechanisms for header protection, and MUAs encountering these messages will need to handle older forms (without Header Protection) for quite some time. An implementation that deals with legacy message archives will need to deal with all the various formats forever. Helping the user distinguish between cryptographic protections of various messages is a difficult job for message renderers.¶
However, on the message generation side, the situation is much clearer: there is a standard form that a protected message can take, and an implementer can always generate the standard form. Generating the standard form also makes it more likely that any receiving implementation will be able to handle the generated message appropriately.¶
The security considerations from Section 6 of [RFC8551] continue to apply for any MUA that offers S/MIME cryptographic protections, as well as Section 3 of [RFC5083] (Authenticated-Enveloped-Data in CMS) and Section 14 of [RFC5652] (CMS more broadly). Likewise, the security considerations from Section 8 of [RFC3156] continue to apply for any MUA that offers PGP/MIME cryptographic protections, as well as Section 13 of [I-D.ietf-openpgp-crypto-refresh-13] (OpenPGP itself). In addition, these underlying security considerations are now also applicable to the contents of the message header, not just the message body.¶
When parsing a message, the recipient MUA infers the message's Cryptographic Status from the Cryptographic Layers, as described in Section 4.6 of [I-D.ietf-lamps-e2e-mail-guidance].¶
The Cryptographic Layers that make up the Cryptographic Envelope describe an ordered list of cryptographic properties as present in the message after it has been delivered.
By contrast, the hp
parameter to the Content-Type
Header Field contains a simpler indication: whether the sender originally tried to encrypt the message or not.
In particular, for a message with Header Protection, the Cryptographic Payload should have a hp
parameter of cipher
if the message is encrypted (in addition to signed), and clear
if no encryption is present (that is, the message is signed-only
).¶
As noted in Section 2.3, the receiving implementation should not inflate its estimation of the confidentiality of the message or its Header Fields based on the sender's intent, if it can see that the message was not actually encrypted.
A signed-only message that happens to have an hp
parameter of cipher
is still signed-only.¶
Conversely, since the encrypting Cryptographic Layer is typically outside the signature layer (see Section 5.2 of [I-D.ietf-lamps-e2e-mail-guidance]), an originally signed-only message could have been wrapped in an encryption layer by an intervening party before receipt, to appear encrypted.¶
If a message appears to be wrapped in an encryption layer, and the hp
parameter is present but is not set to cipher
, then it is likely that the encryption layer was not added by the original sender.
For such a message, the lack of any HP-Outer
Header Field in the Header Section of the Cryptographic Payload MUST NOT be used to infer that all Header Fields were removed from the message by the original sender.
In such a case, the receiving MUA SHOULD treat every Header Field as though it was not confidential.¶
When composing a message, it's possible for a Legacy Display Element to contain risky data that could trigger errors in a rendering client.¶
For example, if the value for a Header Field to be included in a Legacy Display Element within a given body part contains folding whitespace, it should be "unfolded" before generating the Legacy Display Element: all contiguous folding whitespace should be replaced with a single space character. Likewise, if the header value was originally encoded with [RFC2047], it should be decoded first to a standard string and re-encoded using the charset appropriate to the target part.¶
When including a Legacy Display Element in a text/plain
part (see Section 2.5.6.1), if the decoded Subject Header Field contains a pair of newlines (e.g., if it is broken across multiple lines by encoded newlines), any newline MUST be stripped from the Legacy Display Element.
If the pair of newlines is not stripped, a receiving MUA that follows the guidance in Section 2.7.3.3.2 might leave the later part of the Legacy Display Element in the rendered message.¶
When including a Legacy Display Element in a text/html
part (see Section 2.5.6.2), any material in the header values should be explicitly HTML escaped to avoid being rendered as part of the HTML.
At a minimum, the characters <
, >
, and &
should be escaped to <
, >
, and &
, respectively (see for example [HTML-ESCAPES]).
If unescaped characters from removed or obscured header values end up in the Legacy Display Element, a receiving MUA that follows the guidance in Section 2.7.3.3.3 might fail to identify the boundaries of the Legacy Display Element, cutting out more than it should, or leaving remnants visible.
And a Legacy MUA parsing such a message might misrender the entire HTML stream, depending on the content of the removed or obscured header values.¶
The Legacy Display Element is a decorative addition solely to enable visibility of obscured or removed Header Fields in decryption-capable Legacy MUAs. When it is produced, it should be generated minimally and strictly, as described above, to avoid damaging the rest of the message.¶
An encrypted e-mail message using S/MIME or PGP/MIME tends to have some amount of predictable plaintext.
For example, the standard MIME headers of the Cryptographic Payload of a message are often a predictable sequence of bytes, even without Header Protection, when they only include the Structural Header Fields MIME-Version
and Content-Type
.
This is a potential risk for known-plaintext attacks.¶
Including protected Header Fields as described in this document increases the amount of known plaintext. Since some of those headers in a reply will be derived from the message being replied to, this also creates a potential risk for chosen-plaintext attacks, in addition to known-plaintext attacks.¶
Modern message encryption mechanisms are expected to be secure against both known-plaintext attacks and chosen-plaintext attacks. An MUA composing an encrypted message should ensure that it is using such a mechanism, regardless of whether it does Header Protection.¶
The encrypted Header Fields of a message may accidentally leak when replying to the message. See the guidance in Section 2.7.8.¶
For encrypted messages, depending on the sender's HCP, some Header Fields may appear both within the Cryptographic Envelope and on the outside of the message (e.g., Date
might exist identically in both places).
Section 2.7.2 identifies such a Header Field as signed-only
.
These Header Fields are clearly not private at all, despite a copy being inside the Cryptographic Envelope.¶
A Header Field whose name and value are not matched verbatim by any HP-Outer
Header Field from the same part will have encrypted-only
or signed-and-encrypted
status.
But even Header Fields with these stronger levels of cryptographic confidentiality protection might not be as private as the user would like.¶
See the examples below.¶
This concern is true for any encrypted data, including the body of the message, not just the Header Fields: if the sender isn't careful, the message contents or session keys can leak in many ways that are beyond the scope of this document. The message recipient has no way in principle to tell whether the apparent confidentiality of any given piece of encrypted content has been broken via channels that they cannot perceive. Additionally, an active intermediary aware of the recipient's public key can always encrypt a cleartext message in transit to give the recipient a false sense of security.¶
For encrypted messages, even with an ambitious HCP that successfully obscures most Header Fields from all transport agents, Header Fields will be ultimately visible to all intended recipients. This can be especially problematic for Header Fields that are not user-facing, which the sender may not expect to be injected by their MUA. Consider the three following examples:¶
The MUA may inject a User-Agent
Header Field that describes itself to every recipient, even though the sender may not want the recipient to know the exact version of their OS, hardware platform, or MUA.¶
The MUA may have an idiosyncratic way of generating a Message-ID
header, which could embed the choice of MUA, a time zone, a hostname, or other subtle information to a knowledgeable recipient.¶
The MUA may erroneously include a Bcc
Header Field in the origheaders
of a copy of a message sent to the named recipient, defeating the purpose of using Bcc
instead of Cc
(see Section 6.4 for more details about risks related to Bcc
).¶
Clearly, no end-to-end cryptographic protection of any Header Field as described in this document will hide such a sensitive field from the intended recipient.
Instead, the composing MUA MUST populate the origheaders
list for any outbound message with only information the recipient should have access to.
This is true for messages without any cryptographic protection as well, of course, and it is even worse there: such a leak is exposed to the transport agents as well as the recipient.
An encrypted message with Header Protection and a more ambitious Header Confidentiality Policy avoid these leaks exposing information to the transport agents but cannot defend against such a leak to the recipient.¶
For example, if the To
and Cc
Header Fields are removed from the unprotected Header Section, the values in those fields might still be inferred with high probability by an adversary who looks at the message either in transit or at rest.
If the message is found in, or being delivered to a mailbox for bob@example.org
, it's likely that Bob was in either To
or Cc
.
Furthermore, encrypted message ciphertext may hint at the recipients: for S/MIME messages, the RecipientInfo
, and for PGP/MIME messages the key ID in the Public Key Encrypted Session Key (PKESK) packets will all hint at a specific set of recipients.
Additionally, an MTA that handles the message may add a Received
Header Field (or some other custom Header Field) that leaks some information about the nature of the delivery.¶
In another example, if the HCP modifies the Date
header to mask out high-resolution time stamps (e.g., rounding to the most recent hour) and to convert the local time zone to UTC, some information about the date of delivery will still be attached to the e-mail.
At the very least, the low resolution, global version of the date will be present on the message.
Additionally, Header Fields like Received
that are added during message delivery might include higher-resolution timestamps.
And if the message lands in a mailbox that is ordered by time of receipt, even its placement in the mailbox and the non-obscured Date
Header Fields of the surrounding messages could leak this information.¶
Some Header Fields like From
may be impossible to fully obscure, as many modern message delivery systems depend on at least domain information in the From
Header Field for determining whether a message is coming from a domain with "good reputation" (that is, from a domain that is not known for leaking spam).
So even if an ambitious HCP opts to remove the human-readable part from any From
Header Field, and to standardize/genericize the local part of the From
address, the domain will still leak.¶
When an encrypted (or signed-and-encrypted) message is in transit, an active intermediary can strip or tamper with any Header Field that appears outside the Cryptographic Envelope. A receiving MUA that naively infers cryptographic status from differences between the external Header Fields and those found in the Cryptographic Envelope could be tricked into overestimating the protections afforded to some Header Fields.¶
For example, if the original sender's HCP passes through the Cc
Header Field unchanged, a cleanly delivered message would indicate that the Cc
Header Field has a cryptographic status of signed
.
But if an intermediary attacker simply removes the Header Field from the unprotected Header Section before forwarding the message, then the naive recipient might believe that the field has a cryptographic status of signed-and-encrypted
.¶
This document offers protection against such an attack by way of the HP-Outer
Header Fields that can be found on the Cryptographic Payload.
If a Header Field appears to have been obscured by inspection of the outer message, but an HP-Outer
Header Field matches it exactly, the receiving MUA can indicate to the user that the Header Field in question may not have been confidential.¶
In such a case, a cautious MUA may render the Header Field in question as signed
(because the sender did not hide it), but still treat it as signed-and-encrypted
during reply, to avoid accidental leakage of the cleartext value in the reply message, as described in Section 2.7.8.1.¶
As noted in Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance], handling Bcc when generating an encrypted e-mail message can be particularly tricky.
With Header Protection, there is an additional wrinkle.
When an encrypted e-mail message with Header Protection has a Bcc'ed recipient, and the composing MUA explicitly includes the Bcc'ed recipient's address in their copy of the message (see the "second method" in Section 3.6.3 of [RFC5322]), that Bcc
Header Field will always be visible to the Bcc'ed recipient.¶
In this scenario, though, the composing MUA has one additional choice: whether to hide the Bcc
Header Field from intervening message transport agents, by returning null
when the HCP is invoked for Bcc
.
If the composing MUA's rationale for including an explicit Bcc
in the copy of the message sent to the Bcc recipient is to ensure deliverability via a message transport agent that inspects message Header Fields, then stripping the Bcc
field during encryption may cause the intervening transport agent to drop the message entirely.
This is why Bcc
is not explicitly stripped in hcp_minimal
.¶
If, on the other hand, deliverability to a Bcc
'ed recipient is not a concern, the most privacy-preserving option is to simply omit the Bcc
Header Field from the protected Header Section in the first place.
An MUA that is capable of receiving and processing such a message can infer that since their user's address was not mentioned in any To
or Cc
Header Field, they were likely a Bcc
recipient.¶
Please also see Section 9.3 of [I-D.ietf-lamps-e2e-mail-guidance] for more discussion about Bcc and encrypted messages.¶
This document requests IANA to register the following Header Field in the "Permanent Message Header Field Names" registry within "Message Headers" in accordance with [RFC3864].¶
Header Field Name | Template | Protocol | Status | Reference |
---|---|---|---|---|
HP-Outer
|
standard | Section 2.5.3 of RFCXXXX |
The Author/Change Controller of these two entries (Section 4.5 of [RFC3864]) should be the IETF itself.¶
This document also defines the Content-Type
parameters known as hp
(in Section 2.3) and hp-scheme
(in Section 2.4).
Consequently, the Content-Type
row in the "Permanent Message Header Field Names" registry should add a reference to this RFC to its "References" column.¶
That is, the current row:¶
Header Field Name | Template | Protocol | Status | Reference |
---|---|---|---|---|
Content-Type
|
MIME | [RFC4021] |
Should be updated to have the following values:¶
Header Field Name | Template | Protocol | Status | Reference |
---|---|---|---|---|
Content-Type
|
MIME | [RFC4021] [RFCXXXX] |
This document also requests IANA to create a new registry in the "Mail Parameters" protocol group titled Mail Header Confidentiality Policies
with the following content:¶
Header Confidentiality Policy Name | Description | Reference | Recommended |
---|---|---|---|
hcp_no_confidentiality
|
No header confidentiality | Section 2.6.3 of RFCXXX (this document) | N |
hcp_minimal
|
Subject Header Field is obscured |
Section 2.6.1 of RFCXXX (this document) | Y |
hcp_strong
|
Remove or obscure everything but From , Date , To , and Cc
|
Section 2.6.2 of RFCXXX (this document) | N |
hcp_example_hide_cc
is mooted as an example in Section 2.5.2 but is not formally registered by this document.¶
Please add the following textual note to this registry:¶
The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 2.6.4.1 of RFC XXX (this document).¶
Adding an entry to this registry with an N
in the "Recommended" column follows the registration policy of SPECIFICATION REQUIRED.
Adding an entry to this registry with a Y
in the "Recommended" column or changing the "Recommended" column in an existing entry (from N
to Y
or vice versa) requires IETF REVIEW.
During IETF REVIEW, the designated expert must also be consulted.
Guidance for the designated expert can be found in Section 2.6.4.1.¶
Thore Göbel identified significant gaps in earlier versions of this document, and proposed concrete and substantial improvements. Thanks to his contributions, the document is clearer, and the protocols described herein are more useful.¶
Additionally, the authors would like to thank the following people who have provided helpful comments and suggestions for this document: Berna Alp, Bernhard E. Reiter, Carl Wallace, Claudio Luck, David Wilson, Hernani Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Michael StJohns, Nicolas Lidzborski, Peter Yee, Phillip Tao, Robert Williams, Rohan Mahy, Roman Danyliw, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.¶
When an e-mail message with end-to-end cryptographic protection is received by a mail user agent, the user might experience many different possible problematic interactions. A message with Header Protection may introduce new forms of user experience failure.¶
In this section, the authors enumerate different kinds of failures we have observed when reviewing, rendering, and replying to messages with different forms of Header Protection in different Legacy MUAs. Different Legacy MUAs demonstrate different subsets of these problems.¶
A conformant MUA would not exhibit any of these problems. An implementer updating their Legacy MUA to be compliant with this specification should consider these concerns and try to avoid them.¶
Recall that "protected" refers to the "inner" values, e.g., the real Subject
, and "unprotected" refers to the "outer" values, e.g., the dummy Subject
.¶
Unprotected Subject
is visible¶
Protected Subject
(on its own) is visible in the body¶
Protected Subject
, Date
, From
, and To
visible in the body¶
User interaction needed to view whole message¶
User interaction needed to view message body¶
User interaction needed to view protected subject¶
Impossible to view protected Subject
¶
Nuisance alarms during user interaction¶
Impossible to view message body¶
Appears as a forwarded message¶
Appears as an attachment¶
Security indicators not visible¶
Security indicators do not identify protection status of Header Fields¶
User has multiple different methods to reply (e.g., reply to outer, reply to inner)¶
User sees English "Subject:" in body despite message itself being in non-English¶
Security indicators do not identify protection status of Header Fields¶
Header Fields in body render with local Header Field names (e.g., showing "Betreff" instead of "Subject") and dates (TZ, locale)¶
Note that the use case here is:¶
User views message, to the point where they can read it¶
User then replies to message, and they are shown a message composition window, which has some UI elements¶
If the MUA has multiple different methods to reply to a message, each way may need to be evaluated separately¶
This section also uses the shorthand UI:x to mean "the UI element that the user can edit that they think of as x."¶
Unprotected Subject
is in UI:subject (instead of the protected Subject
)¶
Protected Subject
is quoted in UI:body (from Legacy Display Element)¶
Protected Subject
leaks when the reply is serialised into MIME¶
Protected Subject
is not anywhere in UI¶
Message body is not visible/quoted in UI:body¶
User cannot reply while viewing protected message¶
Reply is not encrypted by default (but is for legacy signed-and-encrypted messages without Header Protection)¶
Unprotected From
or Reply-To
is in UI:To (instead of the protected From
or Reply-To
)¶
User's locale (lang, TZ) leaks in quoted body¶
Header Fields not protected (and in particular, Subject
is not obscured) by default¶
This section contains sample messages using the different schemes described in this document. Each sample contains a MIME object, a textual and diagrammatic view of its structure, and examples of how an MUA might render it.¶
The cryptographic protections used in this document use the S/MIME standard, and keying material and certificates come from [I-D.ietf-lamps-samples].¶
These messages should be accessible to any IMAP client at imap://bob@header-protection.cmrg.net/
(any password should authenticate to this read-only IMAP mailbox).¶
You can also download copies of these test vectors separately at https://header-protection.cmrg.net
.¶
If any of the messages downloaded differ from those offered here, this document is the canonical source.¶
These messages offer no header protection at all, and can be used as a baseline. They are provided in this document as a counterexample. An MUA implementer can use these messages to verify that the reported cryptographic summary of the message indicates no header protection.¶
This message uses no cryptographic protection at all. Its body is a text/plain message.¶
It has the following structure:¶
└─╴text/plain 152 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 3852 bytes ⇩ (unwraps to) └─╴text/plain 204 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 4191 bytes ├─╴text/plain 224 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 6720 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 3960 bytes ⇩ (unwraps to) └─╴text/plain 240 bytes¶
Its contents are:¶
This message uses no cryptographic protection at all. Its body is a multipart/alternative message with an inline image/png attachment.¶
It has the following structure:¶
└┬╴multipart/mixed 1406 bytes ├┬╴multipart/alternative 794 bytes │├─╴text/plain 206 bytes │└─╴text/html 304 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5249 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1288 bytes ├┬╴multipart/alternative 882 bytes │├─╴text/plain 258 bytes │└─╴text/html 353 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└┬╴multipart/signed 5234 bytes ├┬╴multipart/mixed 1344 bytes │├┬╴multipart/alternative 938 bytes ││├─╴text/plain 278 bytes ││└─╴text/html 376 bytes │└─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses no header protection.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8690 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5430 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1358 bytes ├┬╴multipart/alternative 952 bytes │├─╴text/plain 294 bytes │└─╴text/html 389 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
These messages are signed-only, using different schemes of header protection and different S/MIME structure. The use no Header Confidentiality Policy because the hcp is only relevant when a message is encrypted.¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4323 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 646 bytes └─╴text/plain 228 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 4566 bytes ├┬╴message/rfc822 inline 676 bytes │└─╴text/plain 256 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4217 bytes ⇩ (unwraps to) └─╴text/plain 239 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a text/plain message. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 4475 bytes ├─╴text/plain 258 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5741 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1693 bytes └┬╴multipart/mixed 1584 bytes ├┬╴multipart/alternative 946 bytes │├─╴text/plain 282 bytes │└─╴text/html 380 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 5657 bytes ├┬╴message/rfc822 inline 1751 bytes │└┬╴multipart/mixed 1642 bytes │ ├┬╴multipart/alternative 1002 bytes │ │├─╴text/plain 310 bytes │ │└─╴text/html 408 bytes │ └─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5684 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1602 bytes ├┬╴multipart/alternative 950 bytes │├─╴text/plain 293 bytes │└─╴text/html 388 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is a signed-only S/MIME message via PKCS#7 detached signature (multipart/signed). The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme.¶
It has the following structure:¶
└┬╴multipart/signed 5568 bytes ├┬╴multipart/mixed 1660 bytes │├┬╴multipart/alternative 1006 bytes ││├─╴text/plain 312 bytes ││└─╴text/html 410 bytes │└─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
These messages are encrypted and signed. They use PKCS#7 signedData inside envelopedData, with different header protection schemes and different Header Confidentiality Policies.¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7995 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4918 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1030 bytes └─╴text/plain 322 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7890 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4824 bytes ⇩ (unwraps to) └─╴text/plain 334 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8125 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5008 bytes ⇩ (unwraps to) └─╴text/plain 424 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7930 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4856 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 985 bytes └─╴text/plain 320 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7780 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4758 bytes ⇩ (unwraps to) └─╴text/plain 332 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8020 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4930 bytes ⇩ (unwraps to) └─╴text/plain 421 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8540 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5306 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1312 bytes └─╴text/plain 328 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8430 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5224 bytes ⇩ (unwraps to) └─╴text/plain 340 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8735 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5454 bytes ⇩ (unwraps to) └─╴text/plain 436 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8170 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5042 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 1120 bytes └─╴text/plain 326 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8040 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4950 bytes ⇩ (unwraps to) └─╴text/plain 338 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8320 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5148 bytes ⇩ (unwraps to) └─╴text/plain 433 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10140 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6498 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2179 bytes └┬╴multipart/mixed 2069 bytes ├┬╴multipart/alternative 1134 bytes │├─╴text/plain 376 bytes │└─╴text/html 474 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10075 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6452 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2089 bytes ├┬╴multipart/alternative 1138 bytes │├─╴text/plain 388 bytes │└─╴text/html 483 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10685 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6898 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2407 bytes ├┬╴multipart/alternative 1433 bytes │├─╴text/plain 486 bytes │└─╴text/html 638 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10055 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6424 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2124 bytes └┬╴multipart/mixed 2014 bytes ├┬╴multipart/alternative 1130 bytes │├─╴text/plain 374 bytes │└─╴text/html 472 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9970 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6374 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2033 bytes ├┬╴multipart/alternative 1134 bytes │├─╴text/plain 386 bytes │└─╴text/html 481 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10555 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6804 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2340 bytes ├┬╴multipart/alternative 1427 bytes │├─╴text/plain 483 bytes │└─╴text/html 635 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10750 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6940 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2501 bytes └┬╴multipart/mixed 2391 bytes ├┬╴multipart/alternative 1146 bytes │├─╴text/plain 382 bytes │└─╴text/html 480 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10705 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6906 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2415 bytes ├┬╴multipart/alternative 1150 bytes │├─╴text/plain 394 bytes │└─╴text/html 489 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_minimal Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 11310 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 7360 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2740 bytes ├┬╴multipart/alternative 1437 bytes │├─╴text/plain 488 bytes │└─╴text/html 640 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Wrapped Message header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10335 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6638 bytes ⇩ (unwraps to) └┬╴message/rfc822 inline 2281 bytes └┬╴multipart/mixed 2171 bytes ├┬╴multipart/alternative 1142 bytes │├─╴text/plain 380 bytes │└─╴text/html 478 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10270 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6596 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2192 bytes ├┬╴multipart/alternative 1146 bytes │├─╴text/plain 392 bytes │└─╴text/html 487 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This is an encrypted and signed S/MIME message using PKCS#7 envelopedData around signedData. The payload is a multipart/alternative message with an inline image/png attachment. It uses the Injected Headers header protection scheme with the hcp_strong Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10900 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 7062 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2527 bytes ├┬╴multipart/alternative 1451 bytes │├─╴text/plain 495 bytes │└─╴text/html 647 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
This section offers step-by-step examples of message composition.¶
A typical MUA composition interface offers the user a place to indicate the message recipients, the subject, and the body. Consider a composition window filled out by the user like so:¶
When Bob clicks "Send", his MUA generates values for Message-ID
, From
, and Date
Header Fields, and converts the message body into the appropriate format.¶
The resulting message would look something like this if it was sent without cryptographic protections:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: Handling the Jones contract Message-ID: <20230111T210843Z.1234@lhp.example> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Please review and approve or decline by Thursday, it's critical! Thanks, Bob -- Bob Gonzalez ACME, Inc.¶
hcp_minimal
and Legacy Display
Now consider the message to be generated if it is to be cryptographically signed and encrypted, using HCP hcp_minimal
, and the legacy
variable is set.¶
For each Header Field, Bob's MUA passes its name and value through hcp_minimal
.
This returns the same value for every Header Field, except that:¶
hcp_minimal
("Subject
", "Handling the Jones contract
") yields "[...]
".¶
The Cryptographic Payload that will be signed and then encrypted is very similar to the unprotected message in Appendix C.1.1. Note the addition of:¶
The hp="cipher"
parameter for the Content-Type
¶
The appropriate HP-Outer
Header Field for Subject
¶
The hp-legacy-display="1"
parameter for the Content-Type
¶
The Legacy Display Element (the simple pseudo-header and its trailing newline) in the Main Body Part.¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: Handling the Jones contract Message-ID: <20230111T210843Z.1234@lhp.example> Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; hp="cipher" MIME-Version: 1.0 HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500 HP-Outer: From: Bob <bob@example.net> HP-Outer: To: Alice <alice@example.net> HP-Outer: Subject: [...] HP-Outer: Message-ID: <20230111T210843Z.1234@lhp.example> Subject: Handling the Jones contract Please review and approve or decline by Thursday, it's critical! Thanks, Bob -- Bob Gonzalez ACME, Inc.¶
The Cryptographic Payload from Appendix C.1.2.1 is then wrapped in the appropriate Cryptographic Layers.
For this example, using S/MIME, it is wrapped in an application/pkcs7-mime; smime-type="signed-data"
layer, which is in turn wrapped in an application/pkcs7-mime; smime-type="enveloped-data"
layer.¶
Then an external Header Section is applied to the outer MIME object, which looks like this:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <bob@example.net> To: Alice <alice@example.net> Subject: [...] Message-ID: <20230111T210843Z.1234@lhp.example> Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type="enveloped-data" MIME-Version: 1.0¶
Note that the Subject
Header Field has been obscured appropriately by hcp_minimal
.
The output of the CMS enveloping operation is base64-encoded and forms the body of the message.¶
This section offers example Cryptographic Payloads (the content within the Cryptographic Envelope) that contain Legacy Display Elements.¶
Here is a simple one-part Cryptographic Payload (Header Section and body) of a message that includes Legacy Display Elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-plain-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; hp="cipher" HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500 HP-Outer: From: Alice <alice@example.net> HP-Outer: To: Bob <bob@example.net> HP-Outer: Subject: [...] HP-Outer: Message-ID: <text-plain-legacy-display@lhp.example> Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and render the body of the message as:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display Elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
Here is a modern one-part Cryptographic Payload (Header Section and body) of a message that includes Legacy Display Elements:¶
Date: Fri, 21 Jan 2022 20:40:48 -0500 From: Alice <alice@example.net> To: Bob <bob@example.net> Subject: Dinner plans Message-ID: <text-html-legacy-display@lhp.example> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii"; hp-legacy-display="1"; hp="cipher" HP-Outer: Date: Fri, 21 Jan 2022 20:40:48 -0500 HP-Outer: From: Alice <alice@example.net> HP-Outer: To: Bob <bob@example.net> HP-Outer: Subject: [...] HP-Outer: Message-ID: <text-html-legacy-display@lhp.example> <html><head><title></title></head><body> <div class="header-protection-legacy-display"> <pre>Subject: Dinner plans</pre> </div> <p> Let's meet at Rama's Roti Shop at 8pm and go to the park from there. </p> </body> </html>¶
A compatible MUA will recognize the hp-legacy-display="1"
parameter and mask out the Legacy Display div
, rendering the body of the message as a simple paragraph:¶
Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
A legacy decryption-capable MUA that is unaware of this mechanism will ignore the hp-legacy-display="1"
parameter and instead render the body including the Legacy Display Elements:¶
Subject: Dinner plans Let's meet at Rama's Roti Shop at 8pm and go to the park from there.¶
Other Header Protection schemes have been proposed in the past. However, those typically have drawbacks such as sparse implementation, known problems with legacy interoperability (in particular with rendering), lack of clear signalling of sender intent, and/or incomplete cryptographic protections. This section lists such schemes known at the time of the publication of this document out of historical interest.¶
S/MIME [RFC8551] (as well as its predecessors [RFC5751] and [RFC3851]) defined a form of cryptographic Header Protection that is similar to the "Wrapped Message" scheme specified in this document. In fact, the scheme originally defined in S/MIME is a subset of the "Wrapped Message" scheme specified in this document. The differences between the original and the updated scheme are outlined in Section 2.2.¶
The pEp (pretty Easy privacy) [I-D.pep-general] project specifies two different MIME schemes that include Header Protection for Signed-and-Encrypted e-mail messages in [I-D.pep-email]: One scheme -- referred as pEp Email Format 1 (PEF-1) -- is generated towards MUAs not known to be pEp-capable, while the other scheme -- referred as PEF-2 -- is used between MUAs discovered to be compatible with pEp. Signed-only messages are not recommended in pEp.¶
[I-D.autocrypt-lamps-protected-headers] describes a scheme similar to the "Injected Headers" scheme specified in this document. However, instead of adding Legacy Display Elements to existing MIME parts (cf. Section 2.5.6.1), "draft-autocrypt" injects a new MIME element "Legacy Display Part", thus modifying the MIME structure of the Cryptographic Payload.¶
[[ RFC Editor: This section is to be removed before publication ]]¶
draft-ietf-lamps-header-protection-21¶
HP-Outer mechanism replaces HP-Removed and HP-Obscured. This enables the recipient to easily calculate the sender's actions around header confidentiality.¶
Replace Content-Type parameter protected-headers=
with hp=
and hp-scheme=
.
The presence of hp=
indicates that the sender used Header Protection according to this document, and the value indicates whether the sender tried to encrypt and sign the message or just sign it.
hp-scheme="wrapped"
advises the recipient that they should look for the protected Header Fields in subtly different place.¶
Provide a clear algorithm for reasonably safe handling of confidential headers during Reply and Forward operations.¶
Do not register the example HCP hcp_hide_cc
, rename to hcp_example_hide_cc
¶
Rename hcp_null
to hcp_no_confidentiality
¶
Provide a clear algorithm for the recipient to compute the protection state of each Header Field.¶
draft-ietf-lamps-header-protection-20¶
draft-ietf-lamps-header-protection-19¶
improve text, capitalize defined terms, fix typos¶
Clean up from AD review:¶
updates RFC 8551 explicitly¶
add "Legacy Signed Message" and "Ordinary User" explicitly to terms¶
tighten up SHOULDs/MUSTs for conformant MUAs¶
expand references to other relevant Security Considerations¶
drop nudge about non-existent Content-Type Parameters registry¶
clarify IANA notes to align with table columns¶
explicitly request HCP registry¶
add references to other header protections schemes, but move all of them to appendix¶
draft-ietf-lamps-header-protection-18¶
only allow US-ASCII as modified output of HCP, adjusted ABNF to match¶
draft-ietf-lamps-header-protection-17¶
draft-ietf-lamps-header-protection-16¶
draft-ietf-lamps-header-protection-15¶
include clarifications, typos, etc from comments received during WGLC¶
draft-ietf-lamps-header-protection-14¶
draft-ietf-lamps-header-protection-13¶
Retitle from "Header Protection for S/MIME" to "Header Protection for Cryptographically Protected E-mail"¶
draft-ietf-lamps-header-protection-12¶
draft-ietf-lamps-header-protection-11¶
Remove most of the Bcc text (transferred general discussion to e2e-mail-guidance)¶
Fix bug in algorithm for generating HP-Obscured and HP-Removed¶
More detail about handling Reply messages¶
Considerations around handling risky Legacy Display Elements¶
Narrative descriptions of some worked examples¶
Describe potential leaks to recipients¶
Clarify debugging/troubleshooting UX affordances¶
draft-ietf-lamps-header-protection-10¶
Clarify that HCP doesn't apply to Structural Header Fields¶
Drop out-of-date "Open Issues" section¶
Brief commentary on UI of messages with intermediate/mixed protections¶
Deprecation prospects for messages without protected headers¶
Describe generating replies to encrypted messages with stronger HCP¶
draft-ietf-lamps-header-protection-09¶
draft-ietf-lamps-header-protection-08¶
draft-ietf-lamps-header-protection-07¶
move from legacy display MIME part to legacy display elements within main body part¶
draft-ietf-lamps-header-protection-06¶
draft-ietf-lamps-header-protection-05¶
fix multipart/signed wrapped test vectors¶
draft-ietf-lamps-header-protection-04¶
draft-ietf-lamps-header-protection-03¶
draft-ietf-lamps-header-protection-02¶
editorial changes / improve language¶
draft-ietf-lamps-header-protection-01¶
Add DKG as co-author¶
Partial Rewrite of Abstract and Introduction [HB/AM/DKG]¶
Adding definitions for Cryptographic Layer, Cryptographic Payload, and Cryptographic Envelope (reference to [I-D.ietf-lamps-e2e-mail-guidance]) [DKG]¶
Enhanced MITM Definition to include Machine- / Meddler-in-the-middle [HB]¶
Relaxed definition of Original message, which may not be of type "message/rfc822" [HB]¶
Move "memory hole" option to the Appendix (on request by Chair to only maintain one option in the specification) [HB]¶
Updated Scope of Protection Levels according to WG discussion during IETF-108 [HB]¶
Obfuscation recommendation only for Subject and Message-Id and distinguish between Encrypted and Unencrypted Messages [HB]¶
Removed (commented out) Header Field Flow Figure (it appeared to be confusing as is was) [HB]¶
draft-ietf-lamps-header-protection-00¶
Initial version (text partially taken over from draft-ietf-lamps-header-protection-requirements¶