Internet-Draft | Cryptographic MIME Header Protection | September 2024 |
Gillmor, et al. | Expires 8 March 2025 | [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. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers.¶
The Header Protection scheme defined here is also applicable to messages with PGP/MIME cryptographic protections.¶
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:[email protected]), 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 8 March 2025.¶
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 how to cryptographically protect message headers, and provides guidance for the implementer of a Mail User Agent (MUA) that generates, interprets, and replies to such a message. It uses the term "Legacy MUA" to refer to an MUA that does not implement this specification. This document takes particular care to ensure that messages interact reasonably well with Legacy MUAs.¶
An older scheme for Header Protection was specified in S/MIME 3.1 ([RFC8551]), which involves wrapping a message/rfc822
MIME object with a Cryptographic Envelope around the message to protect.
This document refers to that scheme as RFC 8551 Header Protection, or "RFC8551HP".
Substantial testing has shown that RFC8551HP does not interact well with some Legacy MUAs (see Section 1.1.1).¶
This specification supersedes RFC8551HP, effectively replacing the final two paragraphs of Section 3.1 of [RFC8551].¶
In this specification, all Header Fields gain end-to-end cryptographic integrity and authenticity by being copied directly into the Cryptographic Payload without using an intervening message/rfc822
MIME object.
In an encrypted message, some Header Fields can also be made confidential by removing or obscuring them from the outer Header Section.¶
This specification also offers substantial security, privacy, and usability guidance for sending and receiving MUAs that was not considered in RFC 8551.¶
Several Legacy MUAs have difficulty rendering a message that uses RFC8551HP. These problems can appear on signed-only messages, as well as signed-and-encrypted messages.¶
In some cases, some mail user agents cannot render message/rfc822
message subparts at all, in violation of baseline MIME requirements as defined on page 5 of [RFC2049].
A message using RFC8551HP is 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.¶
Furthermore, RFC8551HP lacks any discussion of the following points, all of which are provided in this specification:¶
Which Header Fields should be given end-to-end cryptographic integrity and authenticity protections (this specification mandates protection of all Header Fields that the sending MUA knows about).¶
How to securely indicate the sender's intent to offer Header Protection and encryption, which lets a receiving MUA detect messages whose cryptographic properties may have been modified in transit (see Section 2.1.1).¶
Which Header Fields should be given end-to-end cryptographic confidentiality protections in an encrypted message, and how (see Section 3).¶
How to securely indicate the sender's choices about which Header Fields were made confidential, which lets a receiving MUA reply or forward an encrypted message safely without accidentally leaking confidential material (see Section 2.2).¶
These stumbling blocks with Legacy MUAs, missing mechanisms, and missing guidance create a strong disincentive for existing MUAs generate messages using RFC8551HP. Because few messages have been produced, there has been little incentive for those MUAs capable of upgrading to bother interpreting them better.¶
In contrast, the mechanisms defined here are safe to adopt and produce messages with very few problems for Legacy MUAs. And, Section 4.10 provides useful guidance for rendering and replying to RFC8551HP messages.¶
Producing a signed-only message using this specification is risk-free. Such a message will render in the same way on any Legacy MUA as a Legacy Signed Message (that is, a signed message without Header Protection). An MUA conformant to this specification that encounters such a message will be able to gain the benefits of end-to-end cryptographic integrity and authenticity for all Header Fields.¶
An encrypted message produced according to this specification that has some user-facing Header Fields removed or obscured may not render as desired in a Legacy MUA.
In particular, those Header Fields that were made confidential will not be visible to the user of a Legacy MUA.
For example, if the Subject
Header Field outside the Cryptographic Envelope is replaced with [...]
, a Legacy MUA will render the [...]
anywhere the Subject
is normally seen.
This is the only risk of producing an encrypted message according to this specification.¶
A workaround "Legacy Display" mechanism is provided in this specification (see Section 2.1.2). Legacy MUAs will render "Legacy Display Elements" to the user, albeit not in the same location that the Header Fields would normally be rendered.¶
Alternately, if the sender of an encrypted message is particularly concerned about the experience of a recipient using a Legacy MUA, and they are willing to accept leaking the user-facing Header Fields, they can simply adopt the No Header Confidentiality Policy (see Section 3.2.3). A signed and encrypted message composed using the No Header Confidentiality Policy offers no usability risk for a reader using a Legacy MUA, and retains end-to-end cryptographic integrity and authenticity properties for all Header Fields for any reader using a conformant MUA. Of course, such a message has the same (non-existent) confidentiality properties for all Header Fields as a Legacy Encrypted Message (that is, an encrypted message made without Header Protection).¶
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 indicators of integrity and 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 the 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 3) 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. DKIM+DMARC typically provide MTA-to-MTA protection, whereas this specification provides MUA-to-MUA protection. This is because DKIM+DMARC are typically applied to messages by (and interpreted by) MTAs, whereas the mechanisms in this document are typically applied and interpreted by MUAs.¶
A receiving MUA that relies on DKIM+DMARC for sender authenticity should note Section 10.1.¶
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 defined in this document. There should be no conflict between DKIM+DMARC and the specification here.¶
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 confidentiality.¶
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 defined 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 (that is, 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 defined 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.¶
Legacy Encrypted Message: an e-mail message that was signed and encrypted by a Legacy MUA, and therefore has no cryptographic authenticity, integrity, or confidentiality protections on any of its Header Fields.¶
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 3.¶
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 5.2) 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.¶
This section gives an overview by providing an example of how MIME messages with Header Protection look like.¶
Consider the following MIME message:¶
A └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) B └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) C └┬╴multipart/alternative; hp="cipher" D ├─╴text/plain; hp-legacy-display="1" E └─╴text/html; hp-legacy-display="1"¶
Observe that:¶
Node A and B are collectively called the Cryptographic Envelope. Node C (including its sub-nodes D and E) is called the Cryptographic Payload ([I-D.ietf-lamps-e2e-mail-guidance]).¶
Node A contains the traditional unprotected ("outer") Header Fields. Node C contains the protected ("inner") Header Fields.¶
The presence of the hp
attribute (see Section 2.1.1) on the Content-Type
of node C allows the receiver to know that the sender applied Header Protection.
Its value allows the receiver to distinguish whether the sender intended for the message to be confidential (hp="cipher"
) or not (hp="clear"
), since encryption may have been added in transit (see Section 10.2).¶
The "outer" Header Section on node A looks as follows:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <[email protected]> To: Alice <[email protected]> Subject: [...] Message-ID: <[email protected]> Content-Type: application/pkcs7-mime; smime-type="enveloped-data" MIME-Version: 1.0¶
The "inner" Header Section on node C looks as follows:¶
Date: Wed, 11 Jan 2023 16:08:43 -0500 From: Bob <[email protected]> To: Alice <[email protected]> Subject: Handling the Jones contract Keywords: Contract, Urgent Message-ID: <[email protected]> Content-Type: multipart/alternative; hp="cipher" MIME-Version: 1.0 HP-Outer: Date: Wed, 11 Jan 2023 16:08:43 -0500 HP-Outer: From: Bob <[email protected]> HP-Outer: To: Alice <[email protected]> HP-Outer: Subject: [...] HP-Outer: Message-ID: <[email protected]>¶
Observe that:¶
Between node C and node A, some Header Fields are copied as-is (Date
, From
, To
, Message-ID
), some are obscured (Subject
), and some are removed (Keywords
).¶
The HP-Outer
Header Fields (see Section 2.2) of node C contain a protected copy of the Header Fields in node A.
The copy allows the receiver to recompute for which Header Fields the sender provided confidentiality by removing or obscuring them.¶
The copying/removing/obscuring and the HP-Outer
only apply to Non-Structural Header Fields, not to Structural Header Fields like Content-Type
or MIME-Version
(see Section 1.1 of [I-D.ietf-lamps-e2e-mail-guidance]).¶
If the sender intends no confidentiality and doesn't encrypt the message, it doesn't remove or obscure Header Fields.
All Non-Structural Header Fields are copied as-is.
No HP-Outer
Header Fields are present.¶
Node D looks as follows:¶
Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; Subject: Handling the Jones contract Keywords: Contract, Urgent Please review and approve or decline by Thursday, it's critical! Thanks, Bob -- Bob Gonzalez ACME, Inc.¶
Observe that:¶
The sender adds the removed and obscured User-Facing Header Fields (see Section 1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]) to the main body (note the empty line after the Content-Type). This is called the Legacy Display Element. It allows a user with a Legacy MUA which doesn't implement this document to understand the message, since the Header Fields will be shown as part of the main body.¶
The hp-legacy-display="1"
attribute (see Section 2.1.2) indicates that the sender added a Legacy Display Element.
This allows receivers that implement this document to recognise the Legacy Display Element and distinguish it from user-added content.
The receiver then hides the Legacy Display Element and doesn't display it to the user.¶
The hp-legacy-display
is added to the node to which it applies, not on any outer nodes (e.g., not to node C).¶
For more examples, see Appendix D and Appendix E.¶
This section describes relevant, backward-compatible extensions to the Internet Message Format ([RFC5322]). Subsequent sections offer concrete guidance for an MUA to make use of these mechanisms, including policy decisions and recommended pseudocode.¶
This document introduces two parameters for the Content-Type
Header Field, which have distinct semantics and use cases.¶
This specification defines a parameter for the Content-Type
Header Field named hp
(for Header Protection).
This parameter is only relevant on the Content-Type
Header Field at the root of the Cryptographic Payload.
The presence of this parameter at the root of the Cryptographic Payload indicates that the sender intends for this message to have end-to-end cryptographic protections for the Header Fields.¶
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 which Header Fields were made confidential.¶
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 4.2).¶
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 specification also defines an hp-legacy-display
parameter for the Content-Type
Header Field.
The only defined value for this parameter is 1
.¶
This parameter is only relevant on a leaf MIME node of Content-Type
text/html
or text/plain
within a well-formed message with end-to-end cryptographic protections.
Its presence indicates that the MIME node it is attached to contains a decorative "Legacy Display Element".
The Legacy Display Element itself is used for backward-compatible visibility of any removed or obscured User-Facing Header Field in a Legacy MUA.¶
Such a Legacy Display Element need not be rendered to the user of an MUA that implements this specification, because the MUA already knows the correct Header Field information, and can render it to the user in the appropriate part of the MUA's user interface rather than in the body of the message.¶
See Section 5.2.2 for how to insert a Legacy Display Element into a text/plain
Main Body Part.
See Section 5.2.3 for how to insert a Legacy Display Element into a text/html
Main Body Part.
See Section 4.5.3 for how to avoid rendering a Legacy Display Element.¶
This document also specifies a new Header Field: HP-Outer
.¶
This Header Field is used only in the Header Section of the Cryptographic Payload of an encrypted message. It is not relevant for signed-only messages. It documents, with the same cryptographic guarantees shared by the rest of the message, the sender's choices about Header Field confidentiality. 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 11.3).¶
The HP-Outer
Header Fields in a message's Cryptographic Payload are useful for ensuring that any confidential Header Field will not be automatically leaked in the clear if the user replies to or forwards the message.
They may also be useful for an MUA that indicates the confidentiality status of any given Header Field to the user.¶
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 Z
is present in Header Section of the Cryptographic Payload, but doesn't appear in an HP-Outer
Header Field value at all, then the sender is effectively asserting that every instance of Z
was made confidential by removal from the Outer Header Section.
Specifically, it means that no Header Field Z
was included on the outside of the message's Cryptographic Envelope by the sender at the time the message was injected into the mail system.¶
See Section 5.2 for how to insert HP-Outer
Header Fields into an encrypted message.
See Section 4.3 for how to determine the end-to-end confidentiality of a given Header Field from an encrypted message with Header Protection using HP-Outer
.
See Section 6.1 for how an MUA can safely reply to (or forward) an encrypted message without leaking confidential Header Fields by default.¶
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 Section 3.2.5 of [RFC5322], but without the obsolete obs-unstruct
option.¶
An MUA composing an encrypted message according to this specification may make any given Header Field confidential by removing it from Header Section outside the Cryptographic Envelope, or by obscuring it by rewriting it to a different value in that outer Header Section. The composing MUA faces a choice for any new message: which Header Fields should be made confidential, and how?¶
This section defines the "Header Confidentiality Policy" (or HCP) as a well-defined abstraction to encourage MUA developers to consider, document, and share reasonable policies across the community. It establishes a registry of known HCPs, defines a small number of simple HCPs in that registry, and makes a recommendation for a reasonable default.¶
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 a consequence of complexities in existing message delivery systems, some of which may reject, drop, or delay messages where all Header Fields are removed from the top-level MIME object.¶
Note that no representation of the HCP itself ever appears "on the wire".
However, the consumer of the encrypted message can see the decisions that were made by the sender's HCP via the HP-Outer
Header Fields (see Section 2.2).¶
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 5.2.¶
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¶
For alignment with common practice as well as the ABNF in Section 2.2.1 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
.¶
The From
Header Field should also be treated specially by the HCP, to enable defense against possible e-mail address spoofing (see Section 10.1).
In particular, for hcp("From", val_in)
, the addr-spec
of val_in
and the addr-spec
of val_out
SHOULD match according to Section 4.4.5, unless the sending MUA has additional knowledge coordinated with the receiving MUA about more subtle addr-spec
equivalence or certificate validity.¶
This document formally defines three Header Confidentiality Policies with known and reasonably well-understood characteristics as a way to compare and contrast different possible behavioral choices for a composing MUA. These definitions are not meant to preclude the creation of other HCPs.¶
(The example hypothetical HCP described in Section 3.1 above, hcp_example_hide_cc
, is deliberately not formally registered, as it has not been evaluated in practice.)¶
The most conservative recommended Header Confidentiality Policy only provides confidentiality for Informational Fields, as defined in Section 3.6.5 of [RFC5322].
These fields are "only human-readable content" and thus their content should not be relevant to transport agents.
Since most Internet messages today do have a Subject
Header Field, and some filtering engines might object to a message without a Subject
, this policy is conservative and merely obscures that Header Field by replacing it with a fixed string [...]
.
By contrast, Comments
and Keywords
are comparatively rare, so these fields are removed entirely from the Outer Header Section.¶
hcp_baseline(name, val_in) → val_out: if lower(name) is 'subject': return '[...]' else if lower(name) is in ['comments', 'keywords']: return null else: return val_in¶
hcp_baseline
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 slightly more ambitious (and therefore more privacy-preserving) Header Confidentiality Policy might avoid leaking human-interpretable data that MTAs generally don't care about.
The additional protected data isn't related to message routing or transport, but but might reveal sensitive information about the sender or their relationship to the recipients.
This "shy" HCP builds on hcp_baseline
, but also:¶
avoids revealing the display-name
of each identified e-mail address, and¶
avoids leaking the sender's locally-configured time zone in the Date
Header Field.¶
hcp_shy(name, val_in) → val_out: if lower(name) is 'from': if val_in is an RFC 5322 mailbox: return the RFC 5322 addr-spec part of val_in if lower(name) in ['to', 'cc']: if val_in is an RFC 5322 mailbox-list: let val_out be an empty mailbox-list for each mailbox in val_in: append the RFC 5322 addr-spec part of mailbox to val_out return val_out if lower(name) is 'date': if val_in is an RFC 5322 date-time: return the UTC form of val_in else if lower(name) is 'subject': return '[...]' else if lower(name) is in ['comments', 'keywords']: return null return val_in¶
hcp_shy
requires more sophisticated parsing and Header Field manipulation, 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 MUST have a default Header Confidentiality Policy that offers confidentiality for the Subject
Header Field at least.
Local policy and configuration may alter this default, but the MUA SHOULD NOT require the user to select an HCP.¶
hcp_baseline
provides confidentiality for the Subject
Header Field by replacing it with the literal string "[...]
".
It also provides confidentiality for the other less common Informational Header Fields (Comments
and Keywords
) by removing them entirely from the outer Header Section.
This is a sensible default because most users treat the Informational Fields of a message (particularly the Subject) the same way that they treat the body, and they are surprised to find that the Subject of an encrypted message is visible.¶
This document does not mandate any particular Header Confidentiality Policy, though it offers guidance for MUA implementers in selecting one in Section 3.3. 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.¶
An MUA MAY offer even more ambitious confidentiality for Header Fields of an encrypted message than defined in Section 3.2.2.
For example, it might implement an HCP that removes the To
and Cc
Header Fields entirely, relying on the SMTP envelope to ensure proper routing.
Or it might remove References
and In-Reply-To
so that message threading is not visible to any MTA.
Any more ambitious choice might result in deliverability, rendering, or usability issues for the relevant messages, so testing and documentation will be valuable to get this right.¶
The authors of this document hope that implementers with deployment experience will document their chosen Header Confidentiality Policy and the rationale behind their choice.¶
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_baseline
) 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
Header Fields 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 four 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 SHOULD render the protected value, and ignore any unprotected counterparts that may be present (with a special exception for the From
Header Field (see Section 4.4).¶
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 7 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).¶
If any Legacy Display Elements are present in the body of the message, it does not render them.¶
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 6 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 using the following test:¶
The Cryptographic Payload has parameter hp
set to "clear"
or "cipher"
.
See Section 4.5 for rendering guidance.¶
When consuming a message, an MUA MUST ignore the hp
parameter to Content-Type
when it encounters it anywhere other than the root of the message's Cryptographic Payload.¶
When a message is encrypted and it uses Header Protection, an MUA extracts 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 a 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.¶
Method Signature:¶
HeaderSetsFromMessage(refmsg) → (refouter, refprotected)
¶
Procedure:¶
Let refheaders
be the list of (h,v)
protected Header Fields found in the root of the Cryptographic Payload¶
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.¶
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 6.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 4.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)
(that is, an element of refprotected
from Section 4.2):¶
Method signature:¶
HeaderFieldProtection(msg, h, v) → protection_state
¶
Procedure:¶
Let ct
be the Content-Type
of the root of the Cryptographic Payload of msg
.¶
Compute (refouter
, refprotected
) from HeaderSetsFromMessage(msg
).¶
If (h, v)
is not in refprotected
):¶
Abort, v
is not a valid value for header h
¶
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 11.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.¶
End-to-end (MUA-to-MUA) Header Protection is good for authenticity, integrity, and confidentiality, but it potentially introduces new issues when an MUA depends on its MTA to authenticate parts of the Header Section. The latter is typically the case in modern e-mail systems.¶
In particular, when an MUA depends on its MTA to ensure that the e-mail address in the (unprotected) From
Header Field is authentic, but the MUA renders the e-mail address of the protected From
Header Field that differs from the address visible to the MTA, this could create a risk of sender address spoofing (see Section 10.1).
This potential risk applies to signed-only messages as well as signed-and-encrypted messages.¶
"From
Header Field Mismatch" is defined as follows:¶
The addr-spec
of the inner From
Header Field doesn't match the addr-spec
of the outer From
Header Field (see Section 4.4.5).¶
Note: The unprotected From
Header Field used in this comparison is the actual outer Header Field (as seen by the MTA), not the value indicated by any potential inner HP-Outer
.¶
"No Valid and Correctly Bound Signature" is defined as follows:¶
There is no valid signature made by a certificate for which the MUA has a valid binding to the protected From
address.
This includes:¶
the message has no signature, or¶
the message has a broken signature, or¶
the message has a valid signature, but the receiving MUA does not see any valid binding between the signing certificate and the addr-spec
of the inner From
Header Field.¶
Note: There are many possible ways that an MUA could choose to validate a certificate-to-address binding. For example, the MUA could ensure the certificate is issued by one of a set of trusted certification authorities, it could rely on the user to do a manual out-of-band comparison, it could rely on a DNSSEC signal ([RFC7929] or [RFC8162]), and so on. It is beyond the scope of this document to describe all possible ways an MUA might validate the certificate-to-address binding, or to choose among them.¶
To mitigate the above described risk of sender address spoofing, an MUA SHOULD warn the user whenever both of the following conditions are met:¶
From
Header Field Mismatch (as defined in Section 4.4.1.1), and¶
No Valid and Correctly Bound Signature (as defined in Section 4.4.1.2)¶
This warning should be comparable to the MUA's warning about messages that are likely spam or phishing, and it SHOULD show both of the non-matching From
Header Fields.¶
Furthermore, a receiving MUA that depends on its MTA to authenticate the unprotected (outer) From
Header Field SHOULD render the outer From
Header Field (as an exception to the guidance in the beginning of Section 4), if both of the following conditions are met:¶
From
Header Field Mismatch (as defined in Section 4.4.1.1), and¶
No Valid and Correctly Bound Signature (as defined in Section 4.4.1.2)¶
An MUA MAY apply a local preference to render a different display name (e.g., from an address book).¶
See Section 10.1.1 for an detailed explanation of this rendering guidance.¶
When responding to a message, an MUA has different ways to populate the recipients of the new message.
Depending on whether it is a Reply, a Reply-All, or a Forward, an MUA may populate the composer view using a combination of the referenced message's From
, To
, Cc
, Reply-To
, Mail-Followup-To
Header Fields, or any other signals.¶
When responding to a message with Header Protection, an MUA MUST only use the protected Header Fields when populating the recipients of the new message.¶
This avoids compromise of message confidentiality when a MITM attacker modifies the unprotected From
address of an encrypted message, attempting to learn the contents through a misdirected reply.
Note that with the rendering guidance above, a MITM attacker can cause the unprotected From
Header Field to be displayed.
Thus when responding, the populated To
address may differ from the rendered From
address.
However, this change in addresses should not cause more user confusion than the address change caused by a Reply-To
in a Legacy Message does.¶
When generating (Section 3.1.1) or consuming (Section 4.4) a protected From
Header Field, the MUA considers the equivalence of two different addr-spec
values.¶
First, the MUA MUST check whether the domain
part of an addr-spec
being compared contains any U-label [RFC5890].
If it does, it MUST be converted to the A-label form is described in [RFC5891]. We call such converted version (or the original domain, if it didn't contain any U-label) "the ASCII version of the domain
part".
Second, the MUA MUST compare the ASCII version of the domain
part of the two addr-spec
s by standard DNS comparison: assume ASCII text, and compare alphabetic characters case-insensitively, as described in Section 3.1 of [RFC1035].
If the domain
parts match, then the two local-part
s are matched against each other.
The simplest and most common comparison for the local-part
is also an ASCII-based, case-insensitive match.
If the MUA has special knowledge about the domain
and, when composing, it can reasonably expect the receiving MUAs to have the same information, it MAY match the local-part
using a more sophisticated and inclusive matching algorithm.¶
It is beyond the scope of this document to recommend a more sophisticated and inclusive matching algorithm.¶
When the Cryptographic Payload's Content-Type
has the parameter hp
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.2, 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 4.5.3.3) or text/plain
(see Section 4.5.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 E.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; }¶
While From
, To
, Cc
, Subject
, and Date
Header Fields 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 6.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 7.¶
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 4.6).¶
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 displayed outside 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].¶
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 defined 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 defined 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 4.5.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 4.5.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.¶
Section 1.1.1 describes some drawbacks to the Header Protection scheme defined in [RFC8551], referred to here as RFC8551HP. An MUA MUST NOT generate an RFC8551HP message. However, for backward compatibility an MUA MAY try to render or respond to such a message as though the message has standard Header Protection.¶
The following two sections contain guidance for identifying, rendering and replying to RFC8551HP messages. Corresponding test vectors are provided in Appendix C.2.5, Appendix C.2.6, and Appendix C.3.17.¶
An RFC8551HP Message can be identified by its MIME structure, given that all of the following conditions are met:¶
It has a well-formed Cryptographic Envelope consisting of at least one Cryptographic Layer as the outermost MIME object.¶
The Cryptographic Payload is a single message/rfc822
object¶
The message that constitutes the Cryptographic Payload does not itself have a well-formed Cryptographic Envelope; that is, its outermost MIME object is not a Cryptographic Layer.¶
No Content-Type
parameter of hp=
is set on either the Cryptographic Payload, or its immediate MIME child.¶
Here is the MIME structure of an example signed-and-encrypted RFC8551HP message:¶
A └─╴application/pkcs7-mime; smime-type="enveloped-data" ↧ (decrypts to) B └─╴application/pkcs7-mime; smime-type="signed-data" ⇩ (unwraps to) C └┬╴message/rfc822 [Cryptographic Payload] D └┬╴multipart/alternative [Rendered Body] E ├─╴text/plain F └─╴text/html¶
When it has precisely identified a message as an RFC8551HP message, an MUA MAY render or respond to that message as though it were a message with Header Protection as defined in this document by making the following adjustments:¶
Rather than rendering the message body as the Cryptographic Payload itself (part C
in the example above), render the RFC8551HP message's body as the MIME subtree that is the Cryptographic Payload's immediate child (part D
).¶
Make a comparable modification to HeaderSetsFromMessage (Section 4.2.1) and HeaderFieldProtection (Section 4.3.1): both algorithms currently look for the protected Header Fields on the Cryptographic Payload (part C
), but they should instead look at the Cryptographic Payload's immediate child (part D
).¶
If the Cryptographic Envelope is signed-only, behave as though there is an hp="clear"
parameter for the Cryptographic Payload; if the Envelope contains encryption, behave as though there is an hp="cipher"
parameter.
That is, infer the sender's cryptographic intent from the structure of the message.¶
If the Cryptographic Envelope contains encryption, further modify HeaderSetsFromMessage to derive refouter
from the actual outer message Header Fields (those found in part A
in the example above), rather than looking for HP-Outer
Header Fields with the other protected Header Fields.
That is, infer Header Field confidentiality based on the unprotected headers.¶
The inferences in the above modifications are not based on any strong end-to-end guarantees. An intervening MTA may tamper with the message's outer Header Section or wrap the message in an encryption layer to undetectably change the recipient's understanding of the confidentiality of the message's Header Fields or the message body itself.¶
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 F.¶
This section describes the process an MUA should use to apply cryptographic protection to an e-mail message with Header Protection.¶
When composing a message with end-to-end cryptographic protections, an MUA SHOULD apply Header Protection.¶
When generating such a message, an MUA MUST add the hp
parameter (see Section 2.1.1) only to the Content-Type
Header Field at the root of the message's Cryptographic Payload.
The value of the parameter MUST indicate whether the Cryptographic Envelope contains a layer that provides encryption.¶
For contrast, we first 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. The inputs to the algorithm are:¶
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.¶
Method Signature:¶
ComposeNoHeaderProtection(origbody, origheaders, crypto) → mime_message
¶
Procedure:¶
To compose a message using Header Protection, the composing MUA uses the following inputs:¶
All the inputs described in Section 5.1¶
hcp
: a Header Confidentiality Policy, as defined in Section 3¶
respond
: 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 6.1), 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 document, 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.2).
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.¶
Method Signature:¶
Compose(origbody, origheaders, crypto,
hcp, respond, refmsg, legacy)
→ mime_message
¶
Procedure:¶
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 5.2.2 for text/plain
and Section 5.2.3 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
, respond
is not null
, and refmsg
itself is encrypted with header protection:¶
Let response_hcp
be a single-use HCP derived from respond
and refmsg
(see Section 6.1)¶
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", "[email protected]"), ("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: [email protected] 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 5.2.2).
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 5.2.2, 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", "[email protected]"), ("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: [email protected]</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 5.2.2).¶
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
.¶
An MUA might create a new message in response to another message, thus acting both as a receiving MUA and as a sending MUA. 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.¶
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 sending the reply or forward 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.¶
When crafting the Header Fields for a reply or forwarded 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.¶
On a high-level, this can be achieved as follows:
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.2.1.¶
See Appendix D.2 for a simple worked example of this process.¶
Below we describe a supporting algorithm to handles this. It produces 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. This is effectively a single-use HCP. The normal sending guidance in Section 5.2 applies this single-use HCP to implement the high-level guidance above.¶
The algorithm takes two inputs:¶
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 an output, it produces an ephemeral single-use Header Confidentiality Policy, specific to this kind of response to this specific message.¶
Method signature:¶
ReferenceHCP(refmsg, respond) → ephemeral_hcp
¶
Procedure:¶
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 4.2¶
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, the From
address 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
Header Fields 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.¶
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.¶
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.¶
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 Header Protection 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 defined in Section 5.2 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_baseline
as recommended in Section 3.3.
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.3.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 9.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 defined 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_baseline
in Section 3.3) 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.¶
Header Protection improves the security of cryptographically protected e-mail messages. Following the guidance in this document improves security for users by more directly aligning the underlying messages with user expectations about confidentiality, authenticity, and integrity.¶
Nevertheless, helping the user distinguish between cryptographic protections of various messages remains a security challenge for MUAs. This is exarcebated by the fact that many existing messages with cryptographic protections do not employ Header Protection. MUAs encountering these messages (e.g., in an archive) will need to handle older forms (without Header Protection) for quite some time, possibly forever.¶
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.¶
If the From
Header Field were treated by the receiving MUA like any other protected Header Field, this scheme would enable sender address spoofing.¶
To prevent sender spoofing, many receiving MUAs implicitly rely on their receiving MTA to inspect the unprotected Header Section and verify that the From
Header Field is authentic.
If a receiving MUA displays a From
address that doesn't match the From
address that the receiving and/or sending MTAs filtered on, the MUA may be vulnerable to spoofing.¶
Consider a malicious MUA that sets the following Header Fields on an encrypted message with Header Protection:¶
Outer: From: <[email protected]>
¶
Inner: HP-Outer: From: <[email protected]>
¶
Inner: From: <[email protected]>
¶
During sending, the MTA of example.com
validates that the sending MUA is authorized to send from [email protected]
.
Since the message is encrypted, the sending and receiving MTAs cannot see the protected Header Fields.
A naive receiving MUA might follow the algorithms in this document without special consideration for the From
Header Field.
Such an MUA might display the email as coming from [email protected]
to the user, resulting in a spoofed address.¶
This problem applies both between domains and within a domain.¶
This problem always applies to signed-and-encrypted messages.
This problem also applies to signed-only messages because MTAs typically do not look at the protected Header Fields when confirming From
address authenticity.¶
Sender address spoofing is relevant for two distinct security properties:¶
Sender authenticity: relevant for rendering the message (which address to show the user?).¶
Message confidentiality: relevant when replying to a message (a reply to the wrong address can leak the message contents).¶
Section 4.4.3 provides guidance for rendering the From
Header Field.
It recommends a receiving MUA that depends on its MTA to authenticate the unprotected (outer) From
Header Field to render the outer From
Header Field, if both of the following conditions are met:¶
From
Header Field Mismatch (as defined in Section 4.4.1.1)¶
No Valid and Correctly Bound Signature (as defined in Section 4.4.1.2)¶
Note: The second condition effectively means that the inner (expected to be protected) From
Header Field appears to have insufficient protection.¶
This may seem surprising since it causes the MUA to render a mix of both protected and unprotected values. This section provides an argument as to why this guidance makes sense.¶
We proceed by case distinction:¶
Case 1: Malicious sending MUA.¶
Attack situation: the sending MUA puts a different inner From
Header Field to spoof the sender address.¶
In this case, it is "better" to fall back and render the outer From
Header Field because this is what the receiving MTA can validate.
Otherwise this document would introduce a new way for senders to spoof the From
address of the message.¶
This does not preclude a future document from updating this document to specify a protocol for legitimate sender address hiding.¶
Case 2: Malicious sending/transiting/receiving MTA (or anyone meddling between MTAs).¶
Attack situation: an on-path attacker changes the outer From
Header Field (possibly with other meddling to break the signature, see below).
Their goal is to get the receiving MUA to show a different From
address than the sending MUA intended (breaking MUA-to-MUA sender authenticity).¶
Case 2.a: The sending MUA submitted an unsigned or encrypted-only message to the email system. In this case, there can be no sender authenticity anyway.¶
Case 2.b: The sending MUA submitted a signed-only message to the email system.¶
Case 2.b.i: The attacker removes or breaks the signature.
In this case, the attacker can also modify the inner From
Header Field to their liking.¶
Case 2.b.ii: The signature is valid, but the receiving MUA does not see any valid binding between the signing certificate and the addr-spec
of the inner From
Header Field.
In this case, there can be no sender authenticity anyways (the certificate could have been generated by the on-path attacker).
This case is indistinguishable from a malicious sending MUA, hence it is "better" to fall back to the outer From
that the MTA can validate.
Note that once the binding is validated (e.g., after an out-of-band comparison), the rendering may change from showing the outer From
address (and a warning) to showing the inner, now validated From
address.
In some cases, the binding may be instantly validated even for previously unseen certificates (e.g., if the certificate is issued by a trusted certification authority).¶
Case 2.c: The sending MUA submitted a signed-and-encrypted message to the email system.¶
Case 2.c.i: The attacker removes or breaks the signature. Note that the signature is inside the ciphertext (see Section 5.2 of [I-D.ietf-lamps-e2e-mail-guidance]). Thus, assuming the encryption is non-malleable, any on-path attacker cannot break the signature while ensuring that the message still decrypts successfully.¶
Case 2.c.ii: The signature is valid, but the receiving MUA does not see any valid binding between the signing certificate and the addr-spec
of the inner From
Header Field.
See case 2.b.ii.¶
As the case distinction shows, the outer From
Header Field is either the preferred fallback (in particular, to avoid introducing a new spoofing channel), or it is just as good (because just as modifiable) as the inner From
Header Field.¶
Rendering the outer From
Header Field does carry the risk of a "temporary downgrade attack" in cases 2.b.ii and 2.c.ii, where a malicious MTA keeps the signature intact but modifies the outer From
Header Field.
The MUA can resolve this temporary downgrade by validating the certificate-to-addr-spec
binding.
If the MUA never does this validation, the entire message could be fake.¶
If there were a signalling channel where the MTA can tell the MUA whether it authenticated the From
Header Field, an MUA could use this in its rendering decision.
In the absence of such a signal, and when end-to-end authenticity is unavailable, this document prefers to fall back to the outer From
Header Field.
This default is based on the assumption that most MTAs apply some filtering based on the outer From
Header Field (whether the MTA can authenticate it or not).
Rendering the unprotected outer From
Header Field (instead of the protected inner one) in case of a mismatch retains this ability for MTAs.¶
If the MUA decides not to rely on the MTA to authenticate the outer From
Header Field, it may prefer the inner From
Header Field.¶
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.1.1, 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 5.2.2), 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 4.5.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 5.2.3), 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 4.5.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 defined 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 6.¶
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 4.3 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 11.4 for more details about risks related to Bcc
).¶
Clearly, no end-to-end cryptographic protection of any Header Field as defined 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 [email protected]
, 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), 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 6.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_baseline
.¶
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 registers an e-mail Header Field, describes parameters for the Content-Type
Header Field, and establishes a registry for Header Confidentiality Policies to facilitate HCP evolution.¶
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.2.1 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.1.1) and hp-legacy-display
(in Section 2.1.2).
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 3.2.3 of RFCXXX (this document) | N |
hcp_baseline
|
Confidentiality for Informational Header Fields: Subject Header Field is obscured, Keywords and Comments are removed |
Section 3.2.1 of RFCXXX (this document) | Y |
hcp_shy
|
Obscure Subject , remove Keywords and Comments , remove the time zone from Date , and obscure display-name s |
Section 3.2.2 of RFCXXX (this document) | N |
hcp_example_hide_cc
is offered as an example in Section 3 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 3.4.2 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 3.4.2.¶
Alexander Krotov identified the risk of From
address spoofing (see Section 10.1) and helped provide guidance to MUAs.¶
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, Daniel Huigens, David Wilson, Hernani Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Michael StJohns, Nicolas Lidzborski, Orie Steele, Peter Yee, Phillip Tao, Robert Williams, Rohan Mahy, Roman Danyliw, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.¶
This document contains guidance with pseudocode descriptions. Each algorithm is listed here for easy reference.¶
Method Name | Description | Reference |
---|---|---|
HeaderSetsFromMessage | Derive "outer" and "protected" sets of Header Fields from a given message | Section 4.2.1 |
HeaderFieldProtection | Calculate cryptographic protections for a Header Field in a given message | Section 4.3.1 |
ReferenceHCP | Produce an ephemeral HCP to use when responding to a given message | Section 6.1.1 |
ComposeNoHeaderProtection | Legacy message composition with end-to-end cryptographic protections (but no header protection) | Section 5.1.1 |
Compose | Compose a message with end-to-end cryptographic protections including header protection | Section 5.2.1 |
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
Header Fields 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
Header Field is in UI:To (instead of the protected From
or Reply-To
Header Field)¶
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 specification defined above. 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 [RFC9216].¶
These messages should be accessible to any IMAP client at imap://[email protected]/
(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] 3856 bytes ⇩ (unwraps to) └─╴text/plain 206 bytes¶
Its contents are:¶
The S/MIME signed-data layer unwraps to:¶
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 4187 bytes ├─╴text/plain 224 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
This is a signed-and-encrypted 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 241 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
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 1402 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] 5253 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1288 bytes ├┬╴multipart/alternative 882 bytes │├─╴text/plain 260 bytes │└─╴text/html 355 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME signed-data layer unwraps to:¶
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 5230 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 a signed-and-encrypted 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] 8710 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5434 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1356 bytes ├┬╴multipart/alternative 950 bytes │├─╴text/plain 295 bytes │└─╴text/html 390 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
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 Header Protection scheme from the draft.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 4189 bytes ⇩ (unwraps to) └─╴text/plain 233 bytes¶
Its contents are:¶
The S/MIME signed-data layer unwraps to:¶
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 Header Protection scheme from the draft.¶
It has the following structure:¶
└┬╴multipart/signed 4435 bytes ├─╴text/plain 250 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 Header Protection scheme from the draft.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5647 bytes ⇩ (unwraps to) └┬╴multipart/mixed 1570 bytes ├┬╴multipart/alternative 934 bytes │├─╴text/plain 287 bytes │└─╴text/html 382 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME signed-data layer unwraps to:¶
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 Header Protection scheme from the draft.¶
It has the following structure:¶
└┬╴multipart/signed 5520 bytes ├┬╴multipart/mixed 1628 bytes │├┬╴multipart/alternative 990 bytes ││├─╴text/plain 304 bytes ││└─╴text/html 402 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 legacy RFC 8551 header protection (RFC8551HP) scheme.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 5696 bytes ⇩ (unwraps to) └┬╴message/rfc822 1660 bytes └┬╴multipart/mixed 1612 bytes ├┬╴multipart/alternative 974 bytes │├─╴text/plain 296 bytes │└─╴text/html 394 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
The S/MIME signed-data layer unwraps to:¶
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 legacy RFC 8551 header protection (RFC8551HP) scheme.¶
It has the following structure:¶
└┬╴multipart/signed 5624 bytes ├┬╴message/rfc822 1718 bytes │└┬╴multipart/mixed 1670 bytes │ ├┬╴multipart/alternative 1030 bytes │ │├─╴text/plain 324 bytes │ │└─╴text/html 422 bytes │ └─╴image/png inline 232 bytes └─╴application/pkcs7-signature [smime.p7s] 3429 bytes¶
Its contents are:¶
These messages are signed and encrypted. They use PKCS#7 signedData inside envelopedData, with different header protection schemes and different Header Confidentiality Policies.¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7825 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4786 bytes ⇩ (unwraps to) └─╴text/plain 329 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8085 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4968 bytes ⇩ (unwraps to) └─╴text/plain 414 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 7760 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 4732 bytes ⇩ (unwraps to) └─╴text/plain 319 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8170 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5046 bytes ⇩ (unwraps to) └─╴text/plain 502 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8300 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5136 bytes ⇩ (unwraps to) └─╴text/plain 335 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8625 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5368 bytes ⇩ (unwraps to) └─╴text/plain 426 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8190 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5054 bytes ⇩ (unwraps to) └─╴text/plain 325 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted S/MIME message using PKCS#7 envelopedData around signedData. The payload is a text/plain message. It uses the Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 8690 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 5418 bytes ⇩ (unwraps to) └─╴text/plain 514 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10035 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6412 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2054 bytes ├┬╴multipart/alternative 1124 bytes │├─╴text/plain 383 bytes │└─╴text/html 478 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10640 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6856 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2367 bytes ├┬╴multipart/alternative 1415 bytes │├─╴text/plain 476 bytes │└─╴text/html 636 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9925 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6342 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2003 bytes ├┬╴multipart/alternative 1104 bytes │├─╴text/plain 373 bytes │└─╴text/html 468 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10920 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 7072 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2519 bytes ├┬╴multipart/alternative 1597 bytes │├─╴text/plain 564 bytes │└─╴text/html 736 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10575 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6820 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2345 bytes ├┬╴multipart/alternative 1136 bytes │├─╴text/plain 389 bytes │└─╴text/html 484 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_baseline Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 11205 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 7278 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2666 bytes ├┬╴multipart/alternative 1419 bytes │├─╴text/plain 478 bytes │└─╴text/html 638 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 10445 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6716 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2273 bytes ├┬╴multipart/alternative 1116 bytes │├─╴text/plain 379 bytes │└─╴text/html 474 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 Header Protection scheme from the draft with the hcp_shy Header Confidentiality Policy with a "Legacy Display" part.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 11505 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 7508 bytes ⇩ (unwraps to) └┬╴multipart/mixed 2832 bytes ├┬╴multipart/alternative 1621 bytes │├─╴text/plain 576 bytes │└─╴text/html 748 bytes └─╴image/png inline 236 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
This is a signed-and-encrypted 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 legacy RFC 8551 header protection (RFC8551HP) scheme with the hcp_baseline Header Confidentiality Policy.¶
It has the following structure:¶
└─╴application/pkcs7-mime [smime.p7m] 9580 bytes ↧ (decrypts to) └─╴application/pkcs7-mime [smime.p7m] 6082 bytes ⇩ (unwraps to) └┬╴message/rfc822 1876 bytes └┬╴multipart/mixed 1828 bytes ├┬╴multipart/alternative 1166 bytes │├─╴text/plain 392 bytes │└─╴text/html 490 bytes └─╴image/png inline 232 bytes¶
Its contents are:¶
The S/MIME enveloped-data layer unwraps to this signed-data part:¶
The inner signed-data layer unwraps to:¶
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 <[email protected]> To: Alice <[email protected]> Subject: Handling the Jones contract Message-ID: <[email protected]> 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_baseline
and Legacy Display
Now consider the message to be generated if it is to be cryptographically signed and encrypted, using HCP hcp_baseline
, and the legacy
variable is set.¶
For each Header Field, Bob's MUA passes its name and value through hcp_baseline
.
This returns the same value for every Header Field, except that:¶
hcp_baseline
("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 D.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 <[email protected]> To: Alice <[email protected]> Subject: Handling the Jones contract Message-ID: <[email protected]> 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 <[email protected]> HP-Outer: To: Alice <[email protected]> HP-Outer: Subject: [...] HP-Outer: Message-ID: <[email protected]> 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 D.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 <[email protected]> To: Alice <[email protected]> Subject: [...] Message-ID: <[email protected]> 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_baseline
.
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 <[email protected]> To: Bob <[email protected]> Subject: Dinner plans Message-ID: <[email protected]> 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 <[email protected]> HP-Outer: To: Bob <[email protected]> HP-Outer: Subject: [...] HP-Outer: Message-ID: <[email protected]> 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 <[email protected]> To: Bob <[email protected]> Subject: Dinner plans Message-ID: <[email protected]> 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 <[email protected]> HP-Outer: To: Bob <[email protected]> HP-Outer: Subject: [...] HP-Outer: Message-ID: <[email protected]> <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 has never reached wide adoption, and has significant drawbacks compared to the mechanism in this draft. See Section 1.1.1 for more discussion of the differences and Section 4.10 for guidance on how to handle such a message.¶
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.¶
Although the PEF-2 scheme is only meant to be used between PEF-2 compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 (in which case they typically render badly). This is due to signalling mechanism limitations.¶
As the PEF-2 scheme is an enhanced variant of the RFC8551HP scheme (with an additional MIME Layer), it is similar to the RFC8551HP scheme (see Section 4.10). The basic PEF-2 MIME structure looks as follows:¶
A └┬╴multipart/encrypted [Outer Message] B ├─╴application/pgp-encrypted C └─╴application/octet-stream inline [Cryptographic Payload] D ↧ (decrypts to) E └┬╴multipart/mixed F ├─╴text/plain G ├┬╴message/rfc822 H │└─╴[Inner Message] I └─╴application/pgp-keys¶
The MIME structure at part H
contains the Inner Message to be rendered to the user.¶
It is possible for a normal MUA to accidentally produce a message that happens to have the same MIME structure as used for PEF-2 messages. Therefore, a PEF-2 message cannot be identified by MIME structure alone.¶
The lack of a mechanism comparable to HP-Outer
(see Section 2.2) makes it impossible for the recipient of a PEF-2 message to safely determine which Header Fields are confidential or not, while forwarding or replying to a message (see Section 6).¶
Note: As this document is not normative for PEF-2 messages, it does not provide any guidance for handling them. Please see [I-D.pep-email] for more guidance.¶
[I-D.autocrypt-lamps-protected-headers] describes a scheme similar to the Header Protection scheme specified in this document. However, instead of adding Legacy Display Elements to existing MIME parts (see Section 5.2.2), "draft-autocrypt" injects a new MIME element "Legacy Display Part", thus modifying the MIME structure of the Cryptographic Payload. These modified Cryptographic Payloads cause significant rendering problems on some common Legacy MUAs.¶
The lack of a mechanism comparable to hp="cipher"
and hp="clear"
(see Section 2.1.1) means the recipient of an encrypted "draft-autocrypt" message cannot be cryptographically certain whether the sender intended for the message to be confidential or not.
The lack of a mechanism comparable to HP-Outer
(see Section 2.2) makes it impossible for the recipient of an encrypted "draft-autocrypt" to safely determine which Header Fields are confidential or not, while forwarding or replying to a message (see Section 6).¶
[[ RFC Editor: This section is to be removed before publication ]]¶
draft-ietf-lamps-header-protection-24¶
draft-ietf-lamps-header-protection-23¶
draft-ietf-lamps-header-protection-22¶
Reorganize document for better readability.¶
Add more details about problems with draft-autocrypt.¶
Rename hcp_minimal
to hcp_baseline
: in addition to obscuring Subject
, it now removes other Informational Header Fields Comments
and Keywords
.¶
Add an example message up front for easier explainability.¶
Unwrap sample message test vectors.¶
Name pseudocode algorithms, number steps.¶
Reply guidance also applies to forwarded messages.¶
hcp_strong
: stop rewriting Message-Id
.¶
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¶
add references to other header protections schemes, but move all of them to appendix¶
draft-ietf-lamps-header-protection-18¶
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¶
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¶
Section 1.7, Paragraph 2.12.1; Section 3, Paragraph 2; Section 3, Paragraph 5; Section 3.1, Paragraph 3; Section 3.1, Paragraph 9; Section 3.1.1, Paragraph 1; Section 3.2, Paragraph 2; Section 3.2.1, Paragraph 3; Section 3.2.2, Paragraph 1; Section 3.2.2, Paragraph 4; Section 3.3, Paragraph 1; Section 3.4.1, Paragraph 1; Section 3.4.2, Paragraph 1; Section 3.4.2, Paragraph 2.1.1; Section 3.4.2, Paragraph 2.3.1; Section 3.4.2, Paragraph 2.4.1; Section 3.4.2, Paragraph 3; Section 4.8.2, Paragraph 3; Section 5.2.1, Paragraph 4.5.2.2.2.1.1; Section 6.1, Paragraph 5; Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 7.8.1; Section 6.1.1, Paragraph 8; Section 8.2, Paragraph 1; Section 8.2, Paragraph 4; Section 8.2, Paragraph 5; Section 8.2, Paragraph 6; Section 9.2, Paragraph 2; Section 9.2, Paragraph 3; Section 11.2, Paragraph 1; Section 11.2.1, Paragraph 1; Section 11.2.3, Paragraph 1; Section 11.2.3, Paragraph 2; Section 11.3, Paragraph 2; Section 11.4, Paragraph 2; Section 12, Paragraph 1; Table 6; Appendix D.1.2, Paragraph 1; Appendix D.2.2, Paragraph 3; Appendix D.2.2, Paragraph 6; Appendix G, Paragraph 2.4.2.4.1; Appendix G, Paragraph 2.6.2.9.1; Appendix G, Paragraph 2.7.2.1.1; Appendix G, Paragraph 2.11.2.2.1; Appendix G, Paragraph 2.13.2.1.1; Appendix G, Paragraph 2.15.2.1.1; Appendix G, Paragraph 2.15.2.5.1; Appendix G, Paragraph 2.16.2.3.1; Appendix G, Paragraph 2.16.2.4.1¶
Section 1.2, Paragraph 4; Section 1.7, Paragraph 2.12.1; Section 3, Paragraph 2; Section 3.1, Paragraph 1; Section 3.2.1, Paragraph 1; Section 3.2.2, Paragraph 1; Section 3.3, Paragraph 1; Section 3.4, Paragraph 1; Section 3.4.1, Paragraph 2; Section 3.4.2, Paragraph 1; Section 4, Paragraph 5.4.1; Section 5.2, Paragraph 2.2.1; Section 6.1, Paragraph 5; Section 6.1, Paragraph 7; Section 6.1.1, Paragraph 3; Section 8.2, Paragraph 1; Section 9.2, Paragraph 1; Section 11.2.1, Paragraph 3; Section 12.3, Paragraph 5.1.1; Appendix C.2, Paragraph 1; Appendix C.3.1, Paragraph 1; Appendix C.3.2, Paragraph 1; Appendix C.3.3, Paragraph 1; Appendix C.3.4, Paragraph 1; Appendix C.3.5, Paragraph 1; Appendix C.3.6, Paragraph 1; Appendix C.3.7, Paragraph 1; Appendix C.3.8, Paragraph 1; Appendix C.3.9, Paragraph 1; Appendix C.3.10, Paragraph 1; Appendix C.3.11, Paragraph 1; Appendix C.3.12, Paragraph 1; Appendix C.3.13, Paragraph 1; Appendix C.3.14, Paragraph 1; Appendix C.3.15, Paragraph 1; Appendix C.3.16, Paragraph 1; Appendix C.3.17, Paragraph 1; Appendix G, Paragraph 2.22.2.4.1¶
Section 4.3.1, Paragraph 4.2.1; Section 4.10.2, Paragraph 2.2.1; Section 4.10.2, Paragraph 2.4.1; Table 6¶
Section 1.1, Paragraph 1; Section 1.1, Paragraph 2; Section 1.1.1, Paragraph 1; Section 1.1.1, Paragraph 2; Section 1.1.1, Paragraph 5; Section 1.1.1, Paragraph 7; Section 1.1.1, Paragraph 8; Section 4.10, Paragraph 1; Section 4.10, Paragraph 2; Section 4.10.1, Paragraph 1; Section 4.10.1, Paragraph 3; Section 4.10.1, Paragraph 5; Section 4.10.2, Paragraph 1; Section 4.10.2, Paragraph 2.1.1; Appendix C.2.5, Paragraph 1; Appendix C.2.6, Paragraph 1; Appendix C.3.17, Paragraph 1; Appendix F.2, Paragraph 3; Appendix G, Paragraph 2.2.2.6.1¶