< draft-ietf-lamps-header-protection-02.txt   draft-ietf-lamps-header-protection-03.txt >
LAMPS Working Group B. Hoeneisen LAMPS Working Group D.K. Gillmor
Internet-Draft pEp Foundation Internet-Draft American Civil Liberties Union
Intended status: Standards Track D.K. Gillmor Intended status: Standards Track B. Hoeneisen
Expires: 7 May 2021 American Civil Liberties Union Expires: 26 August 2021 pEp Foundation
A. Melnikov A. Melnikov
Isode Ltd Isode Ltd
3 November 2020 22 February 2021
Header Protection for S/MIME Header Protection for S/MIME
draft-ietf-lamps-header-protection-02 draft-ietf-lamps-header-protection-03
Abstract Abstract
S/MIME version 3.1 has introduced a feasible standardized option to S/MIME version 3.1 has introduced a feasible standardized option to
accomplish Header Protection. However, implementations of Header accomplish Header Protection. However, few implementations generate
Protection can cause rendering issues on the receiving side. Clearer messages using this structure, and several legacy and non-legacy
specifications regarding message processing, particularly with implementations have revealed rendering issues at the receiving side.
respect to header sections, are needed in order to resolve these Clearer specifications regarding message processing, particularly
rendering issues. with respect to header sections, are needed in order to resolve these
rendering issues. Some mail user agents are also sending and
receiving cryptographically-protected message headers using a
different structure.
In order to help implementers to correctly compose and render email In order to help implementers to correctly compose and render email
messages with Header Protection, this document updates S/MIME Header messages with Header Protection, this document updates S/MIME Header
Protection specifications with additional guidance on MIME format, Protection specifications with additional guidance on MIME format,
sender and receiver processing. sender and receiver processing.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 43 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 May 2021. This Internet-Draft will expire on 26 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Other Protocols to Protect Email Headers . . . . . . . . 4 1.1. Two Schemes of Protected Headers . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Problems with Wrapped Messages . . . . . . . . . . . . . 4
1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Other Protocols to Protect Email Headers . . . . . . . . 5
2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8 2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 8 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 8 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 10 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 10
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 12
4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 14 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 18 4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 18 4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 18 4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 19 4.1.3. Default Header Confidentiality Policy . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4.1.4. Receiving Side . . . . . . . . . . . . . . . . . . . 22
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Usability Considerations . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 5.1. Mixed Protections Within a Message Are Hard To
9.2. Informative References . . . . . . . . . . . . . . . . . 21 Understand . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Additional information . . . . . . . . . . . . . . . 22
A.1. Stored Variants of Messages with Bcc . . . . . . . . . . 22 5.2. Users Should Not Have To Choose a Header Confidentiality
Appendix B. Text Moved from Above . . . . . . . . . . . . . . . 23 Policy . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
B.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 23 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
Appendix C. Document Changelog . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 35
A.1. Wrapped Message examples . . . . . . . . . . . . . . . . 35
A.1.1. Wrapped Message: signed-only, with PKCS7
signedData . . . . . . . . . . . . . . . . . . . . . 35
A.1.2. Wrapped Message: signed-only, using multipart/
signed . . . . . . . . . . . . . . . . . . . . . . . 35
A.1.3. Wrapped Message: signed-and-encrypted . . . . . . . . 35
A.2. Injected Headers examples . . . . . . . . . . . . . . . . 35
A.2.1. Injected Headers: signed-only, with PKCS7
signedData . . . . . . . . . . . . . . . . . . . . . 35
A.2.2. Injected Headers: signed-only, using multipart/
signed . . . . . . . . . . . . . . . . . . . . . . . 36
A.2.3. Injected Headers: signed-and-encrypted with Legacy
Display part . . . . . . . . . . . . . . . . . . . . 36
A.2.4. Injected Headers: signed-and-encrypted without Legacy
Display part . . . . . . . . . . . . . . . . . . . . 36
A.3. Messages without Header Protection . . . . . . . . . . . 36
A.3.1. Unprotected Headers: signed-only, with PKCS7
signedData . . . . . . . . . . . . . . . . . . . . . 36
A.3.2. Unprotected Headers: signed-only, using multipart/
signed . . . . . . . . . . . . . . . . . . . . . . . 36
A.3.3. Unprotected Headers: signed-and-encrypted . . . . . . 36
Appendix B. Additional information . . . . . . . . . . . . . . . 36
B.1. Stored Variants of Messages with Bcc . . . . . . . . . . 36
Appendix C. Text Moved from Above . . . . . . . . . . . . . . . 37
C.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 37
C.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 37
C.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 40
Appendix D. Document Considerations . . . . . . . . . . . . . . 44
Appendix E. Document Changelog . . . . . . . . . . . . . . . . . 45
Appendix F. Open Issues . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Privacy and security issues regarding email Header Protection in S/ Privacy and security issues regarding email Header Protection in S/
MIME have been identified for some time. Most current MIME have been identified for some time. Most current
implementations of cryptographically-protected electronic mail implementations of cryptographically-protected electronic mail
protect only the body of the message, which leaves significant room protect only the body of the message, which leaves significant room
for attacks against otherwise-protected messages. For example, lack for attacks against otherwise-protected messages. For example, lack
of header protection allows an attacker to substitute the message of header protection allows an attacker to substitute the message
subject and/or author. subject and/or author.
A way to provide end-to-end protection for the Header Section of an This document describes two different structures for how message
email message has been standardized for S/MIME version 3.1 and later headers can be cryptographically protected, and provides guidance for
(cf. [RFC8551]): implementers of MUAs that generate and interpret such messages. It
takes particular care to ensure that messages interact reasonably
well with legacy MUAs.
In order to protect outer, non-content-related message header 1.1. Two Schemes of Protected Headers
fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a
message/RFC822 wrapper in order to apply S/MIME security services
to these header fields.
Unfortunately, implementations of Header Protection can cause Unfortunately, there are two different schemes for cryptographically-
rendering issues on the receiving side. In some cases, the user sees protected email headers that may be in use on the Internet today.
an attachment suggesting a forwarded email message, which - in fact - This document addresses them both and provides guidance to
contains the protected email message that should be rendered implementers.
directly. For these cases, the user can click on the attachment to
view the protected message. However, there have also been reports of One scheme is the form specified in S/MIME 3.1 and later, which
email clients displaying garbled text, or sometimes nothing at all. involves wrapping a "message/rfc822" MIME object with a Cryptographic
In those cases the email clients on the receiving side are (most Envelope. This document calls this scheme "Wrapped Message", and it
likely) not fully MIME-capable. is documented in more detail in [RFC8551]. Experience has shown that
this form does not interact well with some legacy MUAs (see
Section 1.2).
Consequently, another form of header protection is produced and
consumed by some MUAs, where the protected headers are placed
directly on the Cryptographic Payload, without using an intervening
"message/*" MIME object. This document calls this scheme "Injected
Headers", and it is documented in more detail in
[I-D.autocrypt-lamps-protected-headers].
1.2. Problems with Wrapped Messages
Several legacy MUAs have revealed rendering issues when dealing with
a message with headers protected by the Wrapped Message scheme. In
some cases the user sees an attachment suggesting a forwarded email
message, which -- in fact -- contains the protected email message
that should be rendered directly. For these cases, the user can
click on the attachment to view the protected message. However,
there have also been reports of email clients displaying garbled
text, or sometimes nothing at all. In those cases the email clients
on the receiving side are (most likely) not fully MIME-capable.
The following shortcomings have been identified to cause these The following shortcomings have been identified to cause these
issues: issues:
* Broken or incomplete implementations * Broken or incomplete implementations
* Lack of a simple means to distinguish "forwarded message" and * Lack of a simple means to distinguish "forwarded message" and
"wrapped message" (for the sake of Header Protection) "wrapped message" (for the sake of Header Protection)
* Not enough guidance with respect to handling of Header Fields on * Not enough guidance with respect to handling of Header Fields on
both the sending and the receiving side both the sending and the receiving side
1.3. Motivation
Furthermore, the need (technical) Data Minimization, which includes Furthermore, the need (technical) Data Minimization, which includes
data sparseness and hiding all technically concealable information, data sparseness and hiding all technically concealable information,
has grown in importance over the past several years. In addition, has grown in importance over the past several years. In addition,
backwards compatibility must be considered when it is possible to do backwards compatibility must be considered when it is possible to do
so without compromising privacy and security. so without compromising privacy and security.
No mechanism for Header Protection has been standardized for PGP/MIME No mechanism for Header Protection has been standardized for PGP/MIME
(Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have (Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have
implemented ad-hoc header-protection, and would like to see a implemented ad-hoc header-protection, and would like to see a
specification that is applicable to both S/MIME and PGP/MIME. specification that is applicable to both S/MIME and PGP/MIME.
skipping to change at page 4, line 24 skipping to change at page 5, line 41
(Section 4) with guidance on MIME format, sender and receiver (Section 4) with guidance on MIME format, sender and receiver
processing . processing .
[I-D.ietf-lamps-header-protection-requirements] defines the [I-D.ietf-lamps-header-protection-requirements] defines the
requirements that this specification is based on. requirements that this specification is based on.
This document is in an early draft state and contains a proposal on This document is in an early draft state and contains a proposal on
which to base future discussions of this topic. In any case, the which to base future discussions of this topic. In any case, the
final mechanism is to be determined by the IETF LAMPS WG. final mechanism is to be determined by the IETF LAMPS WG.
1.1. Other Protocols to Protect Email Headers 1.4. Other Protocols to Protect Email Headers
A range of protocols for the protection of electronic mail (email) A range of protocols for the protection of electronic mail (email)
exists, which allows one to assess the authenticity and integrity of exists, which allows one to assess the authenticity and integrity of
the email headers section or selected Header Fields from the domain- the email headers section or selected Header Fields from the domain-
level perspective, specifically DomainKeys Identified Mail (DKIM) level perspective, specifically DomainKeys Identified Mail (DKIM)
However, integrity protection and proof of authenticity are both tied [RFC6376], as used by Domain-based Message Authentication, Reporting,
to the domain name of the sending e-mail address, not the sending and Conformance (DMARC) [RFC7489]. These protocols provide a domain-
address itself, so these protocols do not provide end-to-end based reputation mechanism that can be used to mitigate some forms of
protection, and are incapable of providing any form of unsolicited email (spam). At the same time, these protocols can
confidentiality.[RFC6376], as used by Domain-based Message provide a level of cryptographic integrity and authenticity for some
Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These headers, depending on how they are used. However, integrity
protocols provide a domain-based reputation mechanism that can be protection and proof of authenticity are both tied to the domain name
used to mitigate some forms of unsolicited email (spam). At the same of the sending e-mail address, not the sending address itself, so
time, these protocols can provide a level of cryptographic integrity these protocols do not provide end-to-end protection, and are
and authenticity for some headers, depending on how they are used. incapable of providing any form of confidentiality.
1.2. Requirements Language 1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Terms 1.6. Terms
The following terms are defined for the scope of this document: The following terms are defined for the scope of this document:
* Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A * Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
form of active wiretapping attack in which the attacker intercepts form of active wiretapping attack in which the attacker intercepts
and selectively modifies communicated data to masquerade as one or and selectively modifies communicated data to masquerade as one or
more of the entities involved in a communication association." more of the entities involved in a communication association."
Note: Historically, MITM has stood for '_Man_-in-the-middle'. Note: Historically, MITM has stood for '_Man_-in-the-middle'.
However, to indicate that the entity in the middle is not always a However, to indicate that the entity in the middle is not always a
skipping to change at page 6, line 6 skipping to change at page 7, line 23
entity [RFC2045], in particular the MIME structure. Each MIME entity [RFC2045], in particular the MIME structure. Each MIME
Header Field name starts with "Content-" prefix. Header Field name starts with "Content-" prefix.
* MIME Header Section (part): The collection of MIME Header Fields. * MIME Header Section (part): The collection of MIME Header Fields.
"MIME Header Section" refers to a Header Sections that contains "MIME Header Section" refers to a Header Sections that contains
only MIME Header Fields, whereas "MIME Header Section part" refers only MIME Header Fields, whereas "MIME Header Section part" refers
to the MIME Header Fields of a Header Section that - in addition to the MIME Header Fields of a Header Section that - in addition
to MIME Header Fields - also contains non-MIME Header Fields. to MIME Header Fields - also contains non-MIME Header Fields.
* Essential Header Fields (EHF): The minimum set of Header Fields an * Essential Header Fields (EHF): The minimum set of Header Fields an
Outer Message Header Section SHOULD contain; cf. Section 4.1.2.4. Outer Message Header Section SHOULD contain; cf. Appendix C.1.2.5.
* Header Protection (HP): cryptographic protection of email Header * Header Protection (HP): cryptographic protection of email Header
Sections (or parts of it) for signatures and/or encryption Sections (or parts of it) for signatures and/or encryption
* Protection Levels (PL): The level of protection applied to a * Protection Levels (PL): The level of protection applied to a
Message, e.g. 'signature and encryption' or 'signature only' (cf. Message, e.g. 'signature and encryption' or 'signature only' (cf.
Section 3.2). Section 3.2).
* Protected: Portions of a message that have had any Protection * Protected: Portions of a message that have had any Protection
Levels applied. Levels applied.
skipping to change at page 6, line 50 skipping to change at page 8, line 24
protection-related processing has been applied on the sending protection-related processing has been applied on the sending
side. If the source is not a "message/rfc822" Message, OrigM is side. If the source is not a "message/rfc822" Message, OrigM is
defined as the "virtual" Message that would be constructed for defined as the "virtual" Message that would be constructed for
sending it as unprotected email. sending it as unprotected email.
* Inner Message (InnerM): The Message to be protected which has had * Inner Message (InnerM): The Message to be protected which has had
wrapping and protection measures aapplied on the sending side OR wrapping and protection measures aapplied on the sending side OR
the resulting Message once decryption and unwrapping on the the resulting Message once decryption and unwrapping on the
receiving side has been performed. Typically, the Inner Message receiving side has been performed. Typically, the Inner Message
is in clear text. The Inner Message is a subset of (or the same is in clear text. The Inner Message is a subset of (or the same
as) the Original Message (cf. Section 4.1.2.1). The Inner as) the Original Message. The Inner Message must be the same on
Message must be the same on the sending and the receiving side. the sending and the receiving side.
* Outer Message (OuterM): The Message as provided to the Submission * Outer Message (OuterM): The Message as provided to the Submission
Entity or received from the last hop respectively. The Outer Entity or received from the last hop respectively. The Outer
Message normally differs on the sending and the receiving side Message normally differs on the sending and the receiving side
(e.g. new Header Fields are added by intermediary nodes). (e.g. new Header Fields are added by intermediary nodes).
* Receiving User Facing Message (RUFM): The Message used for * Receiving User Facing Message (RUFM): The Message used for
rendering at the receiving side. Typically this is the same as rendering at the receiving side. Typically this is the same as
the Inner Message. the Inner Message.
* Data Minimization: Data sparseness and hiding of all technically * Data Minimization: Data sparseness and hiding of all technically
concealable information whenever possible. concealable information whenever possible.
* Cryptographic Layer, Cryptographic Payload, and Cryptographic * Cryptographic Layer, Cryptographic Payload, Cryptographic
Envelope are all used as defined in Envelope, Structural Headers, and MUA are all used as defined in
[I-D.dkg-lamps-e2e-mail-guidance] [I-D.dkg-lamps-e2e-mail-guidance]
* User-Facing Headers are defined in
[I-D.autocrypt-lamps-protected-headers].
* Legacy MUA: a MUA that does not understand protected headers as
described in this document. A Legacy Non-Crypto MUA is incapable
of doing any end-to-end cryptographic operations. A Legacy Crypto
MUA is capable of doing cryptographic operations, but does not
understand or generate protected headers.
* Wrapped Message: The protected headers scheme that uses the
mechanism described in [RFC8551], where the Cryptographic Payload
is a "message/rfc822" or "message/global" MIME object.
* Injected Headers: The protected headers scheme that uses the
mechanism described in [I-D.autocrypt-lamps-protected-headers],
where the protected headers are inserted on the Cryptographic
Payload directly.
* Header Confidentiality Policy: documented in Section 4.1.2.2
2. Problem Statement 2. Problem Statement
The LAMPS charter contains the following Work Item: The LAMPS charter contains the following Work Item:
Update the specification for the cryptographic protection of email Update the specification for the cryptographic protection of email
headers - both for signatures and encryption - to improve the headers -- both for signatures and encryption -- to improve the
implementation situation with respect to privacy, security, implementation situation with respect to privacy, security,
usability and interoperability in cryptographically-protected usability and interoperability in cryptographically-protected
electronic mail. Most current implementations of electronic mail. Most current implementations of
cryptographically-protected electronic mail protect only the body cryptographically-protected electronic mail protect only the body
of the message, which leaves significant room for attacks against of the message, which leaves significant room for attacks against
otherwise-protected messages. otherwise-protected messages.
In the following a set of challenges to be addressed: In the following a set of challenges to be addressed:
[[ TODO: Enhance this section, add more items to the following. ]] [[ TODO: Enhance this section, add more items to the following. ]]
skipping to change at page 9, line 9 skipping to change at page 11, line 9
Regarding backward compatibility, the main distinction is based on Regarding backward compatibility, the main distinction is based on
whether or not the receiving side conforms to MIME according to whether or not the receiving side conforms to MIME according to
[RFC2046], ff., which in particular also includes Section 2 of [RFC2046], ff., which in particular also includes Section 2 of
[RFC2049] on "MIME Conformance". The following excerpt is [RFC2049] on "MIME Conformance". The following excerpt is
contextually relevant: contextually relevant:
A mail user agent that is MIME-conformant MUST: A mail user agent that is MIME-conformant MUST:
[...] [...]
-- Recognize and display at least the RFC822 message -- Recognize and display at least the RFC822 message
encapsulation (message/rfc822) in such a way as to encapsulation (message/rfc822) in such a way as to
preserve any recursive structure, that is, displaying preserve any recursive structure, that is, displaying
or offering to display the encapsulated data in or offering to display the encapsulated data in
accordance with its media type. accordance with its media type.
-- Treat any unrecognized subtypes as if they were -- Treat any unrecognized subtypes as if they were
"application/octet-stream". "application/octet-stream".
[...] [...]
An MUA that meets the above conditions is said to be MIME- An MUA that meets the above conditions is said to be MIME-
conformant. A MIME-conformant MUA is assumed to be "safe" to send conformant. A MIME-conformant MUA is assumed to be "safe" to
virtually any kind of properly-marked data to users of such mail send virtually any kind of properly-marked data to users of
systems, because these systems are, at a minimum, capable of treating such mail systems, because these systems are, at a minimum,
the data as undifferentiated binary, and will not simply capable of treating the data as undifferentiated binary, and
splash it onto the screen of unsuspecting users. will not simply splash it onto the screen of unsuspecting
users.
[[ TODO: The compatibility of legacy HP systems with this new [[ TODO: The compatibility of legacy HP systems with this new
solution, and how to handle issues surrounding future maintenance for solution, and how to handle issues surrounding future maintenance for
these legacy systems, will be decided by the LAMPS WG. ]] these legacy systems, will be decided by the LAMPS WG. ]]
3.1.2.1. Receiving Side MIME-Conformant 3.1.2.1. Receiving Side MIME-Conformant
The sending side (fully) supports Header Protection as specified in The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this this document, while the receiving side does not support this
specification. However, the receiving side is MIME-conformant specification. However, the receiving side is MIME-conformant
skipping to change at page 13, line 49 skipping to change at page 15, line 49
(Outer Message Body) is protected. The Outer Message Body consists (Outer Message Body) is protected. The Outer Message Body consists
of the wrapper (MIME Header Section) and the Inner Message (Header of the wrapper (MIME Header Section) and the Inner Message (Header
Section and Body). Section and Body).
The wrapper is a simple MIME Header Section with media type "message/ The wrapper is a simple MIME Header Section with media type "message/
rfc822" containing a Content-Type header field parameter rfc822" containing a Content-Type header field parameter
"forwarded=no" followed by an empty line. "forwarded=no" followed by an empty line.
If the source is an Original (message/rfc822) Message, the Inner If the source is an Original (message/rfc822) Message, the Inner
Message Header Section is typically the same as (or a subset of) the Message Header Section is typically the same as (or a subset of) the
Original Message Header Section (cf. Section 4.1.2.1), and the Inner Original Message Header Section, and the Inner Message Body is
Message Body is typically the same as the Original Message Body. typically the same as the Original Message Body.
The Inner Message itself may contain any MIME structure. The Inner Message itself may contain any MIME structure.
Note: It is still to be decided by the LAMPS WG whether or not to Note: It is still to be decided by the LAMPS WG whether or not to
recommend an alternative MIME format as described in Appendix B.1.1.1 recommend an alternative MIME format as described in Appendix C.1.1.1
(instead of the currently standardized and above defined format). (instead of the currently standardized and above defined format).
4.1.2. Sending Side 4.1.2. Sending Side
To ease explanation, the following describes the case where an This section describes the process an MUA should use to apply
Original (message/rfc822) Message to be protected is present. If cryptographic protection to an e-mail message with header protection.
this is not the case, Original Message means the (virtual) Message We start by describing the legacy message composition process as a
that would be constructed for sending it as unprotected email. baseline.
4.1.2.1. Inner Message Header Fields 4.1.2.1. Composing a Cryptographically-Protected Message Without Header
Protection
It is RECOMMENDED that the Inner Message contains all Header Fields [I-D.dkg-lamps-e2e-mail-guidance] describes the typical process for a
of the Original Message with the exception of the following Header legacy crypto MUA to apply cryptographic protections to an e-mail
Field, which MUST NOT be included within the Inner Message nor within message. That guidance and terminology is replicated here for
any other protected part of the Message: reference:
* Bcc * "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 headers
("Content-*") present.
[[ TODO: Bcc handling needs to be further specified (see also * "origheaders": the intended non-structural headers for the
Appendix A.1). Certain MUAs cannot properly decrypt Messages with message, represented here as a list of "(h,v)" pairs, where "h" is
Bcc recipients. ]] 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 during composition, but plans to omit it from the
message (see section 3.6.3 of [RFC5322]), it will not be in
"origheaders".
4.1.2.2. Wrapper * "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 wrapper is a simple MIME Header Section followed by an empty line The algorithm returns a MIME object that is ready to be injected into
preceding the Inner Message (inside the Outer Message Body). The the mail system:
media type of the wrapper MUST be "message/RFC822" and MUST contain
the Content-Type header field parameter "forwarded=no" as defined in
[I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously
delimits the Inner Message from the rest of the Message.
4.1.2.3. Cryptographic Layers / Envelope * Apply "crypto" to "origbody", yielding MIME tree "output"
[[ TODO: Basically refer to S/MIME standards ]] * For each header name and value "(h,v)" in "origheaders":
4.1.2.4. Outer Message Header Fields - Add header "h" of "output" with value "v"
4.1.2.4.1. Encrypted Messages * Return "output"
To maximize Privacy, it is strongly RECOMMENDED to follow the 4.1.2.2. Header Confidentiality Policy
principle of Data Minimization (cf. Section 2.1).
However, the Outer Message Header Section SHOULD contain the When composing an encrypted message with protected headers, the
Essential Header Fields and, in addition, MUST contain the Header composing MUA needs a Header Confidentialiy Policy. In this
Fields of the MIME Header Section part to describe Cryptographic document, we represent that Header Confidentiality Policy as a
Layer of the protected MIME subtree as per [RFC8551]. function "hcp":
The following Header Fields are defined as the Essential Header * "hcp(name, val_in) --> val_out": this function takes a header
Fields: field name "name" and initial value "val_in" as arguments, and
returns a replacement header value "val_out". If "val_out" is the
special value "null", it mean that the header in question should
be omitted from the set of headers visible outside the
Cryptographic Envelope.
* From For example, an MUA that only obscures the "Subject" header field by
replacing it with the literal string "[...]" and does not offer
confidentiality to any other header fields would be represented as
(in pseudocode):
* To (if present in the Original Message) "hcp(name, val_in) --> val_out: if name is 'Subject': return '[...]'
else: return val_in"
* Cc (if present in the Original Message) 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.
* Bcc (if present in the Original Message, see also Section 4.1.2.1 This asymmetry is an unfortunate consequence of complexities in
and Appendix A.1) message delivery systems, some of which may reject, drop, or delay
messages where all headers are removed from the top-level MIME
object.
* Date This document does not mandate any particular Header Confidentiality
Policy, though it offers guidance for MUA implementers in selecting
one in Section 4.1.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.
* Message-ID 4.1.2.3. Composing with "Wrapped Message" Header Protection
* Subject To compose a message using "Wrapped Message" header protection, we
use those inputs described in Section 4.1.2.1 plus the Header
Confidentiality Policy "hcp" defined in Section 4.1.2.2. The new
algorithm is:
Further processing by the Submission Entity normally depends on part * For header name and value "(h,v)" in "origheaders":
of these Header Fields, e.g. From and Date HFs are required by
[RFC5322]. Furthermore, not including certain Header Fields may
trigger spam detection to flag the Message, and/or lead to user
experience (UX) issues.
For further Data Minimization, the value of the Subject Header Field - Add header "h" of "origbody" with value "v"
SHOULD be obfuscated as follows:
* Subject: [...] * If any of the header fields in "origbody", including headers in
the nested internal MIME structure, contain any 8-bit UTF-8
characters (see section section 3.7 of [RFC6532]):
and it is RECOMMENDED to replace the Message-ID by a new randomly - Let "payload" be a new MIME part with one header: "Content-
generated Message-ID. Type: message/global; forwarded=no", and whose body is
"origbody".
In addition, the value of other Essential Header Fields MAY be * Else:
obfuscated.
Non-Essential Header Fields SHOULD be omitted from the Outer Message - Let "payload" be a new MIME part with one header: "Content-
Header Section where possible. If Non-essential Header Fields are Type: message/rfc822; forwarded=no", and whose body is
included in the Outer Message Header Section, those MAY be obfuscated "origbody".
too.
Header Fields that are not obfuscated should contain the same values * Apply "crypto" to "payload", yielding MIME tree "output"
as in the Original Message.
If an implementation obfuscates the From, To, and/or Cc Header * If "crypto" contains encryption:
Fields, it may need to provide access to the clear text content of
these Header Fields to the Submission Entity for processing purposes.
This is particularly relevant, if proprietary Submission Entities are
used. Obfuscation of Header Fields may adversely impact spam
filtering.
(A use case for obfuscation of all Outer Message Header Fields is - Create new empty list of header field names and values "newh"
routing email through the use of onion routing or mix networks, e.g.
[pEp.mixnet].)
The MIME Header Section part is the collection of MIME Header Fields - For header name and value "(h,v)" in "origheaders":
describing the following MIME structure as defined in [RFC2045]. A
MIME Header Section part typically includes the following Header
Fields:
* Content-Type o Let "newval" be "hcp(h, v)"
* Content-Transfer-Encoding o If "newval" is not "null":
* Content-Disposition + Append "(h,newval)" to "newh"
The following example shows the MIME Header Section part of an S/MIME - Set "origheaders" to "newh"
signed Message (using application/pkcs7-mime with SignedData):
MIME-Version: 1.0 * For header name and value "(h,v)" in "origheaders":
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Depending on the scenario, further Header Fields MAY be exposed in - Add header "h" of "output" with value "v"
the Outer Message Header Section, which is NOT RECOMMENDED unless
justified. Such Header Fields may include e.g.:
* References * Return "output"
Note that the Header Confidentiality Policy "hcp" is ignored if
"crypto" does not contain encryption. This is by design.
* Reply-To 4.1.2.4. Composing with "Injected Headers" Header Protection
* In-Reply-To To compose a message using "Injected Headers" header protection, the
composing MUA needs one additional input in addition to the Header
Confidentiality Policy "hcp" defined in Section 4.1.2.2.
4.1.2.4.2. Unencrypted Messages * "legacy": a boolean value, indicating whether any recipient of the
message is believed to have a legacy client. If all recipients
are known to implement this draft, "legacy" should be set to
"false". (How a MUA determines the value of "legacy" is out of
scope for this document; an initial implementation can simply set
it to "true")
The Outer Message Header Section of unencrypted Messages SHOULD The revised algorithm for applying cryptographic protection to a
contain at least the Essential Header Fields and, in addition, MUST message is as follows:
contain the Header Fields of the MIME Header Section part to describe
Cryptographic Layer of the protected MIME subtree as per [RFC8551].
It may contain further Header Fields, in particular those also
present in the Inner Message Header Section.
4.1.2.5. Sending Side Message Processing * Create a new MIME leaf part "legacydisplay" with header "Content-
Type: text/plain; protected-headers="v1"" and an empty body.
For a protected Message the following steps are applied before a * if "crypto" contains encryption, and "legacy" is "true":
Message is handed over to the Submission Entity:
4.1.2.5.1. Step 1: Decide on Protection Level and Information - For each header name and value "(h,v)" in "origheaders":
Disclosure
The implementation which applies protection to a Message must decide: o If "h" is user-facing (see
[I-D.autocrypt-lamps-protected-headers]):
* Which Protection Level (signature and/or encryption) shall be + If "hcp(h,v)" is not "v":
applied to the Message? This depends on user request and/or local
policy as well as availability of cryptographic keys.
* Which Header Fields of the Original Message shall be part of the * Add "h: v" to the body of "legacydisplay". For
Outer Message Header Section? This typically depends on local example, if "h" is "Subject", and "v" is "lunch
policy. By default, the Essential Header Fields are part of the plans?", then add the line "Subject: lunch plans?" to
Outer Message Header Section; cf. Section 4.1.2.4. the body of "legacydisplay"
* Which of these Header Fields are to be obfuscated? This depends * If the body of "legacydisplay" is empty:
on local policy and/or specific Privacy requirements of the user.
By default only the Subject Header Field is obfuscated; cf.
Section 4.1.2.4.
4.1.2.5.2. Step 2: Compose the Outer Message Header Section - Let "payload" be MIME part "origbody", discarding
"legacydisplay"
Depending on the decision in Section 4.1.2.5.1, the implementation * Else: (body of "legacydisplay" is not empty)
shall compose the Outer Message Header Section. (Note that this also
includes the necessary MIME Header Section part for the following
protection layer.)
Outer Header Fields that are not obfuscated should contain the same - Construct a new MIME part "wrapper" with "Content-Type:
values as in the Original Message (except for MIME Header multipart/mixed"
Section part, which depends on the Protection Level selected in
Section 4.1.2.5.1).
4.1.2.5.3. Step 3: Apply Protection to the Original Message - Give "wrapper" exactly two subparts: "legacydisplay" and
"origbody", in that order.
Depending on the Protection Level selected in Section 4.1.2.5.1, the - Let "payload" be MIME part "wrapper"
implementation applies signature and/or encryption to the Original
Message, including the wrapper (as per [RFC8551]), and sets the
resulting package as the Outer Message Body.
The resulting (Outer) Message is then typically handed over to the * For each header name and value "(h,v)" in "origheaders":
Submission Entity.
[[ TODO: Example ]] - Add header "h" of MIME part "payload" with value "v"
4.1.3. Receiving Side * Set the "protected-headers" parameter on the "Content-Type" of
"payload" to "v1"
4.1.3.1. Receiving User Facing Message Header Fields * Apply "crypto" to "payload", producing MIME tree "output"
The Receiving User Facing Message SHOULD be a verbatim copy of the * If "crypto" contains encryption:
Inner Message.
4.1.3.2. Receiving Side Message Processing - Create new empty list of header field names and values "newh"
When a protected Message is received, the following steps are - For header name and value "(h,v)" in "origheaders":
applied:
4.1.3.2.1. Step 1: Decrypt Message and/or check signature o Let "newval" be "hcp(h, v)"
Depending on the Protection Level, the received Message is decrypted o If "newval" is not "null":
and/or its signature is checked as per [RFC8551].
4.1.3.2.2. Step 2: Construct the Receiving User Facing Message + Add "newh[h]" to "newval"
The Receiving User Facing Message is constructed according to - Set "origheaders" to "newh"
Section 4.1.3.1.
The resulting Message is handed over for further processing, which * For each header name and value "(h,v)" in "origheaders":
typically involves rendering it for the user.
4.1.3.3. Step 3: Prepare Information Cyptographic Verification - Add header "h" of "output" with value "v"
[[ TODO: Signature valid, etc. ]] * Return "output"
4.2. Backward Compatibility Use Cases 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.
4.1.2.5. Choosing Between Wrapped Message and Injected Headers
When composing a message with end-to-end cryptographic protections,
an MUA SHOULD protect the headers of that message as well as the
body.
An MUA MAY protect the headers of any outbound message using either
the "Wrapped Message" or the "Injected Headers" style of protection.
See Section 4.2 for more discussion about reasons to choose one
mechanism or another.
[[ TODO: this document should recommend generation of one particular
scheme by default for new implementers ]]
4.1.3. Default Header Confidentiality Policy
An MUA SHOULD have a sensible default Header Confidentiality Policy,
and SHOULD NOT require the user to select one.
The default Header Confidentiality Policy SHOULD provide
confidentiality for the "Subject" header field by replacing it with
the literal string "[...]". Most users treat the Subject of a
message the same way that they treat the body, and they are surprised
to find that the Subject of an encrypted message is visible.
[[ TODO: select one of the two policies below the recommended default
]]
4.1.3.1. Minimalist Header Confidentiality Policy
Accordingly, the most conservative recommended Header Confidentiality
Policy only protects the "Subject":
"hcp_minimal(name, val_in) --> val_out: if name is 'Subject': return
'[...]' else: return val_in"
4.1.3.2. Strong Header Confidentiality Policy
Alternately, a more aggressive (and therefore more privacy-
preserving) Header Confidentiality Policy only leaks a handful of
fields whose absence is known to increase rates of delivery failure,
and simultaneously obscures the "Message-ID" behind a random new one:
"hcp_strong(name, val_in) --> val_out: if name in ['From', 'To',
'Cc', 'Date']: return val_in else if name is 'Subject': return
'[...]' else if name is 'Message-ID': return
generate_new_message_id() else: return null"
The function "generate_new_message_id()" represents whatever process
the MUA typically uses to generate a "Message-ID" for a new outbound
message.
4.1.3.3. Offering Stronger Header Confidentiality
A MUA MAY offer even stronger confidentiality for headers of an
encrypted message than described in Section 4.1.3.2. For example, it
might implement an HCP that obfuscates the "From" field, or omits the
"Cc" field, or ensures "Date" is represented in "UTC" (obscuring the
local timezone).
The authors of this document hope that implementers with deployment
experience will document their chosen Header Confidentiality Policy
and the rationale behind their choice.
4.1.4. Receiving Side
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
[I-D.dkg-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, few MUAs typically render "Message-Id" or "Received" header
fields for the user, but most do render "From", "To", "Cc", "Date",
and "Subject".
A MUA that knows how to handle a message with protected headers makes
the following two changes to its behavior when rendering a message:
* If it detects that an incoming message had protected headers, it
renders header fields for the message from the protected headers,
ignoring the external (unprotected) headers.
* It includes information in the message's cryptographic summary to
indicate the types of protection that applied to each rendered
header field (if any).
A MUA that handles protected headers does _not_ need to render any
new header fields that it did not render before.
4.1.4.1. Identifying that a Message has Protected Headers
An incoming message can be identified as having protected headers
based on one of two signals:
* The Cryptographic Payload has "Content-Type: message/rfc822" or
"Content-Type: message/global" and the parameter "forwarded" has a
value of "no". See Section 4.1.4.3 for rendering guidance.
* The Cryptographic Payload has some other "Content-Type" and it has
parameter "protected-headers" set to "v1". See Section 4.1.4.4
for rendering guidance.
Messages of both types exist in the wild, and a sensible MUA should
be able to handle them both. They provide the same semantics and the
same meaning.
4.1.4.2. Updating the Cryptographic Summary
Regardless of whether a cryptographically-protected message has
protected headers, the cryptographic summary of the message should be
modified to indicate what protections the headers have.
Each header individually has exactly one the following protections:
* "unprotected" (this is the case for all headers in messages that
have no protected headers)
* "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 was either omitted or
obfuscated)
* "encrypted-and-signed" (same as encrypted, but additionally is
under a validatd signature)
Note that while the message itself may be "encrypted-and-signed",
some headers may be replicated on the outside of the message (e.g.
"Date") Those headers would be "signed-only", despite the message
itself being "encrypted-and-signed".
Rendering this information 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.
4.1.4.3. Rendering a Wrapped Message
When the Cryptographic Payload has "Content-Type" of "message/rfc822"
or "message/global", and the parameter "forwarded" is set to "no",
the values of the protected headers are drawn from the headers of the
Cryptographic Payload, and the body that is rendered is the body of
the Cryptographic Payload.
4.1.4.3.1. Example Signed-Only Wrapped Message
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 └┬╴message/rfc822 [Cryptographic Payload]
C └┬╴multipart/alternative [Rendered Body]
D ├─╴text/plain
E └─╴text/html
The message body should be rendered the same way as this message:
C └┬╴multipart/alternative
D ├─╴text/plain
E └─╴text/html
It should render header fields taken from part "C".
Its cryptographic summary should indicates that the message was
signed and all rendered header fields were included in the signature.
The MUA SHOULD ignore header fields from part "A" for the purposes of
rendering.
4.1.4.3.2. Example Encrypted-and-Signed Wrapped Message
Consider a message with this structure, where the MUA is able to
validate the cryptographic signature:
F └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to)
G └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
H └┬╴message/rfc822 [Cryptographic Payload]
I └┬╴multipart/alternative [Rendered Body]
J ├─╴text/plain
K └─╴text/html
The message body should be rendered the same way as this message:
I └┬╴multipart/alternative
J ├─╴text/plain
K └─╴text/html
It should render headers taken from part "I".
Its cryptographic summary should indicates that the message was
signed and encrypted. Each rendered header field found in "I" should
be compared against the header field of the same name from "F". If
the value found in "F" matches the value found in "I", the header
field should be marked as "signed-only". If no matching header field
was found in "F", or the value found did not match the value from
"I", the header field should be marked as "signed-and-encrypted".
4.1.4.4. Rendering a Message with Injected Headers
When the Cryptographic Payload does not have a "Content-Type" of
"message/rfc822" or "message/global", and the parameter "protected-
headers" is set to "v1", the values of the protected headers are
drawn from the headers of the Cryptographic Payload, and the body
that is rendered is the Cryptographic Payload itself.
4.1.4.4.1. Example Signed-only Message with Injected Headers
L └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
M └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
N ├─╴text/plain
O └─╴text/html
The message body should be rendered the same way as this message:
M └┬╴multipart/alternative
N ├─╴text/plain
O └─╴text/html
It should render header fieldss taken from part "M".
Its cryptographic summary should indicates that the message was
signed and all rendered header fields were included in the signature.
The MUA SHOULD ignore header fields from part "L" for the purposes of
rendering.
4.1.4.4.2. Example Signed-and-Encrypted Message with Injected Headers
Consider a message with this structure, where the MUA is able to
validate the cryptographic signature:
P └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to)
Q └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
R └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
S ├─╴text/plain
T └─╴text/html
The message body should be rendered the same way as this message:
R └┬╴multipart/alternative
S ├─╴text/plain
T └─╴text/html
It should render headers taken from part "R".
Its cryptographic summary should indicates that the message was
signed and encrypted. As in Section 4.1.4.3.2, each rendered header
field found in "R" should be compared against the header field of the
same name from "P". If the value found in "P" matches the value
found in "R", the header field should be marked as "signed-only". If
no matching header field was found in "P", or the value found did not
match the value from "R", the header field should be marked as
"signed-and-encrypted".
4.1.4.4.3. Do Not Render Legacy Display Part
As described [I-D.autocrypt-lamps-protected-headers], a message with
cryptographic confidentiality protection MAY include a "Legacy
Display" part for backward-compatibility with legacy MUAs
The receiving MUA SHOULD avoid rendering the Legacy Display part to
the user at all, since it is aware of and can render the actual
Protected Headers.
If a Legacy Display part is detected, it and its enclosing
"multipart/mixed" wrapper should be discarded before rendering.
4.1.4.4.3.1. Legacy Display Detection Algorithm
A receiving MUA acting on a message SHOULD detect the presence of a
Legacy Display part and the corresponding "original body" with the
following simple algorithm:
* Check that all of the following are true for the message:
* The Cryptographic Envelope must contain an encrypting
Cryptographic Layer
* The Cryptographic Payload must have a "Content-Type" of
"multipart/mixed"
* The Cryptographic Payload must have exactly two subparts
* The first subpart of the Cryptographic Payload must have a
"Content-Type" of "text/plain" or "text/rfc822-headers"
* The first subpart of the Cryptographic Payload's "Content-Type"
must contain a property of "protected-headers", and its value must
be "v1".
* If all of the above are true, then the first subpart is the Legacy
Display part, and the second subpart is the "original body".
Otherwise, the message does not have a Legacy Display part.
4.1.4.4.3.2. Legacy Display Example
Consider a message with this structure, where the MUA is able to
validate the cryptographic signature:
U └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to)
V └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
W └┬╴multipart/mixed [Cryptographic Payload]
X ├─╴text/plain [Legacy Display]
Y └┬╴multipart/alternative [Rendered Body]
Z ├─╴text/plain
A' └─╴text/html
The message body should be rendered the same way as this message,
effectively hiding the Legacy Display part ("X") and its wrapper:
Y └┬╴multipart/alternative
Z ├─╴text/plain
A' └─╴text/html
It should render headers taken from part "W", following the same
guidance as in Section 4.1.4.4.2 and Section 4.1.4.3.2 about the
cryptographic status of each rendered header field.
4.1.4.5. Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original
message, for example to troubleshoot problems with the MUA itself, or
problems with the SMTP transport path taken by the message.
A 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.
4.1.4.6. Composing a Reply to an Encrypted Message with Protected
Headers
When composing a reply to an encrypted message with protected
headers, the MUA is acting both as a receiving MUA and as a sending
MUA. Special guidance applies here, as things can go wrong in at
least two ways: leaking previously-confidential information, and
replying to the wrong party.
4.1.4.6.1. Avoid Leaking Encrypted Headers in Reply
As noted in [I-D.dkg-lamps-e2e-mail-guidance], an MUA in this
position MUST NOT leak previously-encrypted content in the clear in a
followup message. The same is true for protected headers.
Values from any header field that was identified as either
"encrypted" 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 obfuscate the "Subject"
field in the cleartext header as described above.
[[ TODO: formally describe how a replying MUA should generate a
message-specific Header Protection policy based on the cryptographic
status of the headers of the incoming message ]]
4.1.4.6.2. Avoid Misdirected Replies to Encrypted Messages with
Protected Headers
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" headers
* optionally, the other "To" or "Cc" headers (if the user chose to
"reply all")
When a message has protected headers, the replying MUA MUST populate
the destination fields of the draft message using the protected
headers, and ignore any unprotected headers.
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 header.
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.
4.1.4.7. Implicitly-rendered Header Fields
While "From" and "To" and "Cc" and "Subject" and "Date" are often
explicitly rendered to the user, some header fields do affect message
display, without being explicitly rendered.
For example, "Message-Id", "References", and "In-Reply-To" header
fields may collectively be used to place a message in a "thread" or
series of messages.
In another example, Section 4.1.4.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 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 protected headers SHOULD use the value from the
protected header, and SHOULD NOT use any value found outside the
cryptographic protection.
4.1.4.8. Unprotected Headers Added in Transit
Some headers are legitimately added in transit, and could not have
been known to the sender at message composition time.
The most common of these headers 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
protected headers.
The MUA MAY prefer to verify that the headers in question have
additional transit-derived cryptographic protections (e.g., to test
whether they are covered by a valid "DKIM-Signature") before
rendering or acting on them.
Specific examples appear below.
4.1.4.8.1. Mailing list headers: List-* and Archived-At
If the message arrives through a mailing list, the list manager
itself may inject headers (most of which start with "List-") in the
message:
* "List-Archive"
* "List-Subscribe"
* "List-Unsubscribe"
* "List-Id"
* "List-Help"
* "List-Post"
* "Archived-At"
For some MUAs, these headers 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 protected headers 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.
FIXME: other examples of unprotected transit headers?
4.2. Backward Compatibility Use Cases
4.2.1. Receiving Side MIME-Conformant 4.2.1. Receiving Side MIME-Conformant
This section applies to the case where the sending side (fully) This section applies to the case where the sending side (fully)
supports Header Protection as specified in this document, while the supports Header Protection as specified in this document, while the
receiving side does not support this specification, but is MIME- receiving side does not support this specification, but is MIME-
conformant according to [RFC2045], ff. (cf. Section 3.1.2 and conformant according to [RFC2045], ff. (cf. Section 3.1.2 and
Section 3.1.2.1) Section 3.1.2.1)
The sending side specification of the main use case (cf. The sending side specification of the main use case (cf.
Section 4.1) MUST ensure that receiving sides can still recognize and Section 4.1) MUST ensure that receiving sides can still recognize and
skipping to change at page 19, line 34 skipping to change at page 32, line 5
Should serious backward compatibility issues with rendering at the Should serious backward compatibility issues with rendering at the
receiving side be discovered, the Legacy Display format described in receiving side be discovered, the Legacy Display format described in
[I-D.autocrypt-lamps-protected-headers] may serve as a basis to [I-D.autocrypt-lamps-protected-headers] may serve as a basis to
mitigate those issues (cf. Section 4.2). mitigate those issues (cf. Section 4.2).
Another variant of backward compatibility has been implemented by pEp Another variant of backward compatibility has been implemented by pEp
[I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has [I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has
implemented this for PGP/MIME, but not yet S/MIME. implemented this for PGP/MIME, but not yet S/MIME.
5. Security Considerations 5. Usability Considerations
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 section in [I-D.dkg-lamps-e2e-mail-guidance].
5.1. Mixed Protections Within a Message Are Hard To Understand
[[ TODO ]] [[ TODO ]]
6. Privacy Considerations 5.2. Users Should Not Have To Choose a Header Confidentiality Policy
[[ TODO ]] [[ TODO ]]
7. IANA Considerations 6. Security Considerations
[[ TODO ]]
7. Privacy Considerations
[[ TODO ]]
8. IANA Considerations
This document requests no action from IANA. This document requests no action from IANA.
[[ RFC Editor: This section may be removed before publication. ]] [[ RFC Editor: This section may be removed before publication. ]]
8. Acknowledgments 9. Acknowledgments
The authors would like to thank the following people who have The authors would like to thank the following people who have
provided helpful comments and suggestions for this document: Berna provided helpful comments and suggestions for this document: Berna
Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista Alp, Claudio Luck, David Wilson, Hernani Marques, juga, Krista
Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ
Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.dkg-lamps-e2e-mail-guidance] [I-D.dkg-lamps-e2e-mail-guidance]
Gillmor, D., "Guidance on End-to-End E-mail Security", Gillmor, D. K., "Guidance on End-to-End E-mail Security",
Work in Progress, Internet-Draft, draft-dkg-lamps-e2e- Work in Progress, Internet-Draft, draft-dkg-lamps-e2e-
mail-guidance-00, 31 October 2020, <http://www.ietf.org/ mail-guidance-01, 22 February 2021,
internet-drafts/draft-dkg-lamps-e2e-mail-guidance-00.txt>. <https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-
guidance-01.txt>.
[I-D.ietf-lamps-header-protection-requirements] [I-D.ietf-lamps-header-protection-requirements]
Melnikov, A. and B. Hoeneisen, "Problem Statement and Melnikov, A. and B. Hoeneisen, "Problem Statement and
Requirements for Header Protection", Work in Progress, Requirements for Header Protection", Work in Progress,
Internet-Draft, draft-ietf-lamps-header-protection- Internet-Draft, draft-ietf-lamps-header-protection-
requirements-01, 29 October 2019, <http://www.ietf.org/ requirements-01, 29 October 2019,
internet-drafts/draft-ietf-lamps-header-protection- <https://www.ietf.org/archive/id/draft-ietf-lamps-header-
requirements-01.txt>. protection-requirements-01.txt>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
skipping to change at page 21, line 12 skipping to change at page 33, line 49
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
9.2. Informative References 10.2. Informative References
[I-D.autocrypt-lamps-protected-headers] [I-D.autocrypt-lamps-protected-headers]
Einarsson, B., juga, j., and D. Gillmor, "Protected Einarsson, B. R., juga, and D. K. Gillmor, "Protected
Headers for Cryptographic E-mail", Work in Progress, Headers for Cryptographic E-mail", Work in Progress,
Internet-Draft, draft-autocrypt-lamps-protected-headers- Internet-Draft, draft-autocrypt-lamps-protected-headers-
02, 20 December 2019, <http://www.ietf.org/internet- 02, 20 December 2019, <https://www.ietf.org/archive/id/
drafts/draft-autocrypt-lamps-protected-headers-02.txt>. draft-autocrypt-lamps-protected-headers-02.txt>.
[I-D.dkg-lamps-samples]
Gillmor, D. K., "S/MIME Example Keys and Certificates",
Work in Progress, Internet-Draft, draft-dkg-lamps-samples-
05, 18 February 2021, <https://www.ietf.org/archive/id/
draft-dkg-lamps-samples-05.txt>.
[I-D.melnikov-iana-reg-forwarded] [I-D.melnikov-iana-reg-forwarded]
Melnikov, A. and B. Hoeneisen, "IANA Registration of Melnikov, A. and B. Hoeneisen, "IANA Registration of
Content-Type Header Field Parameter 'forwarded'", Work in Content-Type Header Field Parameter 'forwarded'", Work in
Progress, Internet-Draft, draft-melnikov-iana-reg- Progress, Internet-Draft, draft-melnikov-iana-reg-
forwarded-00, 4 November 2019, <http://www.ietf.org/ forwarded-00, 4 November 2019,
internet-drafts/draft-melnikov-iana-reg-forwarded-00.txt>. <https://www.ietf.org/archive/id/draft-melnikov-iana-reg-
forwarded-00.txt>.
[I-D.pep-email] [I-D.pep-email]
Marques, H., "pretty Easy privacy (pEp): Email Formats and Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", Work in Progress, Internet-Draft, draft-pep- Protocols", Work in Progress, Internet-Draft, draft-pep-
email-00, 10 July 2020, <http://www.ietf.org/internet- email-01, 2 November 2020,
drafts/draft-pep-email-00.txt>. <https://www.ietf.org/archive/id/draft-pep-email-01.txt>.
[pEp.mixnet] [pEp.mixnet]
pEp Foundation, "Mixnet", June 2020, pEp Foundation, "Mixnet", June 2020,
<https://dev.pep.foundation/Mixnet>. <https://dev.pep.foundation/Mixnet>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001, DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/info/rfc3156>. <https://www.rfc-editor.org/info/rfc3156>.
skipping to change at page 22, line 9 skipping to change at page 35, line 5
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>. <https://www.rfc-editor.org/info/rfc6409>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
Appendix A. Additional information Appendix A. Test Vectors
A.1. Stored Variants of Messages with Bcc This section contains sample messages using the different schemes
described in this document. Each sample contains a MIME object, and
examples of how an MUA might render it.
The cryptographic protections used in this document use the S/MIME
standard, and keying material and certificates come from
[I-D.dkg-lamps-samples].
For the signed-and-encrypted messages, only the "Subject" header is
obscured.
A.1. Wrapped Message examples
The examples in this subsection use the "Wrapped Message" header
protection scheme.
A.1.1. Wrapped Message: signed-only, with PKCS7 signedData
[[ TODO ]]
A.1.2. Wrapped Message: signed-only, using multipart/signed
[[ TODO ]]
A.1.3. Wrapped Message: signed-and-encrypted
[[ TODO ]]
A.2. Injected Headers examples
The examples in this subsection use the "Injected Headers" header
protection scheme.
A.2.1. Injected Headers: signed-only, with PKCS7 signedData
[[ TODO ]]
A.2.2. Injected Headers: signed-only, using multipart/signed
[[ TODO ]]
A.2.3. Injected Headers: signed-and-encrypted with Legacy Display part
[[ TODO ]]
A.2.4. Injected Headers: signed-and-encrypted without Legacy Display
part
[[ TODO ]]
A.3. Messages without Header Protection
The examples in this subsection have cryptographic protection, but no
header protection. 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.
A.3.1. Unprotected Headers: signed-only, with PKCS7 signedData
[[ TODO ]]
A.3.2. Unprotected Headers: signed-only, using multipart/signed
[[ TODO ]]
A.3.3. Unprotected Headers: signed-and-encrypted
[[ TODO ]]
Appendix B. Additional information
B.1. Stored Variants of Messages with Bcc
Messages containing at least one recipient address in the Bcc header Messages containing at least one recipient address in the Bcc header
field may appear in up to three different variants: field may appear in up to three different variants:
1. The Message for the recipient addresses listed in To or Cc header 1. The Message for the recipient addresses listed in To or Cc header
fields, which must not include the Bcc header field neither for fields, which must not include the Bcc header field neither for
signature calculation nor for encryption. signature calculation nor for encryption.
2. The Message(s) sent to the recipient addresses in the Bcc header 2. The Message(s) sent to the recipient addresses in the Bcc header
field, which depends on the implementation: field, which depends on the implementation:
skipping to change at page 23, line 5 skipping to change at page 37, line 27
3. The Message stored in the 'Sent'-Folder of the sender, which 3. The Message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original Message, usually contains the Bcc unchanged from the original Message,
i.e., with all recipient addresses. i.e., with all recipient addresses.
The most privacy preserving method of the alternatives (2a, 2b, and The most privacy preserving method of the alternatives (2a, 2b, and
2c) is to standardize 2a, as in the other cases (2b and 2c), 2c) is to standardize 2a, as in the other cases (2b and 2c),
information about hidden recipients is revealed via keys. In any information about hidden recipients is revealed via keys. In any
case, the Message has to be cloned and adjusted depending on the case, the Message has to be cloned and adjusted depending on the
recipient. recipient.
Appendix B. Text Moved from Above Appendix C. Text Moved from Above
Note: Per an explicit request by the chair of the LAMPS WG to only Note: Per an explicit request by the chair of the LAMPS WG to only
present one option for the specification, the following text has been present one option for the specification, the following text has been
stripped from the main body of the draft. It is preserved in an stripped from the main body of the draft. It is preserved in an
Appendix for the time being and may be moved back to the main body or Appendix for the time being and may be moved back to the main body or
deleted, depending on the decision of the LAMPS WG. deleted, depending on the decision of the LAMPS WG.
B.1. MIME Format C.1. MIME Format
Currently there are two options in discussion: Currently there are two options in discussion:
1. The option according to the current S/MIME specification (cf. 1. The option according to the current S/MIME specification (cf.
[RFC8551]) [RFC8551])
2. An alternative option that is based on the former "memory hole" 2. An alternative option that is based on the former "memory hole"
approach (cf. [I-D.autocrypt-lamps-protected-headers]) approach (cf. [I-D.autocrypt-lamps-protected-headers])
B.1.1. S/MIME Specification C.1.1. S/MIME Specification
Note: This is currently described in the main part of this document. Note: This is currently described in the main part of this document.
B.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory C.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
Hole") Hole")
An alternative option (based on the former autocrypt "Memory Hole" An alternative option (based on the former autocrypt "Memory Hole"
approach) to be considered, is described in approach) to be considered, is described in
[I-D.autocrypt-lamps-protected-headers]. [I-D.autocrypt-lamps-protected-headers].
Unlike the option described in Appendix B.1.1, this option does not Unlike the option described in Appendix C.1.1, this option does not
use a "message/RFC822" wrapper to unambiguously delimit the Inner use a "message/RFC822" wrapper to unambiguously delimit the Inner
Message. Message.
Before choosing this option, the following two issues must be Before choosing this option, the following two issues must be
assessed to ensure no interoperability issues result from it: assessed to ensure no interoperability issues result from it:
1. How current MIME parser implementations treat non-MIME Header 1. How current MIME parser implementations treat non-MIME Header
Fields, which are not part of the outermost MIME entity and not Fields, which are not part of the outermost MIME entity and not
part of a Message wrapped into a MIME entity of media type part of a Message wrapped into a MIME entity of media type
"message/rfc822", and how such Messages are rendered to the user. "message/rfc822", and how such Messages are rendered to the user.
skipping to change at page 25, line 40 skipping to change at page 40, line 40
[[base-64 encoded signature]] [[base-64 encoded signature]]
--boundary-AM-- --boundary-AM--
The Outer Message Header Section is unprotected, while the remainder The Outer Message Header Section is unprotected, while the remainder
(Outer Message Body) is protected. The Outer Message Body consists (Outer Message Body) is protected. The Outer Message Body consists
of the Inner Message (Header Section and Body). of the Inner Message (Header Section and Body).
The Inner Message Header Section is the same as (or a subset of) the The Inner Message Header Section is the same as (or a subset of) the
Original Message Header Section (cf. Section 4.1.2.1). Original Message Header Section.
The Inner Message Body is the same as the Original Message Body. The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any MIME structure. The Original Message itself may contain any MIME structure.
Appendix C. Document Changelog C.1.2. Sending Side
To ease explanation, the following describes the case where an
Original (message/rfc822) Message to be protected is present. If
this is not the case, Original Message means the (virtual) Message
that would be constructed for sending it as unprotected email.
C.1.2.1. Inner Message Header Fields
It is RECOMMENDED that the Inner Message contains all Header Fields
of the Original Message with the exception of the following Header
Field, which MUST NOT be included within the Inner Message nor within
any other protected part of the Message:
* Bcc
[[ TODO: Bcc handling needs to be further specified (see also
Appendix B.1). Certain MUAs cannot properly decrypt Messages with
Bcc recipients. ]]
C.1.2.2. Wrapper
The wrapper is a simple MIME Header Section followed by an empty line
preceding the Inner Message (inside the Outer Message Body). The
media type of the wrapper MUST be "message/RFC822" and MUST contain
the Content-Type header field parameter "forwarded=no" as defined in
[I-D.melnikov-iana-reg-forwarded]. The wrapper unambiguously
delimits the Inner Message from the rest of the Message.
C.1.2.3. Cryptographic Layers / Envelope
[[ TODO: Basically refer to S/MIME standards ]]
C.1.2.4. Sending Side Message Processing
For a protected Message the following steps are applied before a
Message is handed over to the Submission Entity:
C.1.2.4.1. Step 1: Decide on Protection Level and Information
Disclosure
The implementation which applies protection to a Message must decide:
* Which Protection Level (signature and/or encryption) shall be
applied to the Message? This depends on user request and/or local
policy as well as availability of cryptographic keys.
* Which Header Fields of the Original Message shall be part of the
Outer Message Header Section? This typically depends on local
policy. By default, the Essential Header Fields are part of the
Outer Message Header Section; cf. Appendix C.1.2.5.
* Which of these Header Fields are to be obfuscated? This depends
on local policy and/or specific Privacy requirements of the user.
By default only the Subject Header Field is obfuscated; cf.
Appendix C.1.2.5.
C.1.2.4.2. Step 2: Compose the Outer Message Header Section
Depending on the decision in Appendix C.1.2.4.1, the implementation
shall compose the Outer Message Header Section. (Note that this also
includes the necessary MIME Header Section part for the following
protection layer.)
Outer Header Fields that are not obfuscated should contain the same
values as in the Original Message (except for MIME Header
Section part, which depends on the Protection Level selected in
Appendix C.1.2.4.1).
C.1.2.4.3. Step 3: Apply Protection to the Original Message
Depending on the Protection Level selected in Appendix C.1.2.4.1, the
implementation applies signature and/or encryption to the Original
Message, including the wrapper (as per [RFC8551]), and sets the
resulting package as the Outer Message Body.
The resulting (Outer) Message is then typically handed over to the
Submission Entity.
[[ TODO: Example ]]
C.1.2.5. Outer Message Header Fields
C.1.2.5.1. Encrypted Messages
To maximize Privacy, it is strongly RECOMMENDED to follow the
principle of Data Minimization (cf. Section 2.1).
However, the Outer Message Header Section SHOULD contain the
Essential Header Fields and, in addition, MUST contain the Header
Fields of the MIME Header Section part to describe Cryptographic
Layer of the protected MIME subtree as per [RFC8551].
The following Header Fields are defined as the Essential Header
Fields:
* From
* To (if present in the Original Message)
* Cc (if present in the Original Message)
* Bcc (if present in the Original Message, see also Appendix B.1)
* Date
* Message-ID
* Subject
Further processing by the Submission Entity normally depends on part
of these Header Fields, e.g. From and Date HFs are required by
[RFC5322]. Furthermore, not including certain Header Fields may
trigger spam detection to flag the Message, and/or lead to user
experience (UX) issues.
For further Data Minimization, the value of the Subject Header Field
SHOULD be obfuscated as follows:
* Subject: [...]
and it is RECOMMENDED to replace the Message-ID by a new randomly
generated Message-ID.
In addition, the value of other Essential Header Fields MAY be
obfuscated.
Non-Essential Header Fields SHOULD be omitted from the Outer Message
Header Section where possible. If Non-essential Header Fields are
included in the Outer Message Header Section, those MAY be obfuscated
too.
Header Fields that are not obfuscated should contain the same values
as in the Original Message.
If an implementation obfuscates the From, To, and/or Cc Header
Fields, it may need to provide access to the clear text content of
these Header Fields to the Submission Entity for processing purposes.
This is particularly relevant, if proprietary Submission Entities are
used. Obfuscation of Header Fields may adversely impact spam
filtering.
(A use case for obfuscation of all Outer Message Header Fields is
routing email through the use of onion routing or mix networks, e.g.
[pEp.mixnet].)
The MIME Header Section part is the collection of MIME Header Fields
describing the following MIME structure as defined in [RFC2045]. A
MIME Header Section part typically includes the following Header
Fields:
* Content-Type
* Content-Transfer-Encoding
* Content-Disposition
The following example shows the MIME Header Section part of an S/MIME
signed Message (using application/pkcs7-mime with SignedData):
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Depending on the scenario, further Header Fields MAY be exposed in
the Outer Message Header Section, which is NOT RECOMMENDED unless
justified. Such Header Fields may include e.g.:
* References
* Reply-To
* In-Reply-To
C.1.2.5.2. Unencrypted Messages
The Outer Message Header Section of unencrypted Messages SHOULD
contain at least the Essential Header Fields and, in addition, MUST
contain the Header Fields of the MIME Header Section part to describe
Cryptographic Layer of the protected MIME subtree as per [RFC8551].
It may contain further Header Fields, in particular those also
present in the Inner Message Header Section.
Appendix D. Document Considerations
[[ RFC Editor: This section is to be removed before publication ]] [[ RFC Editor: This section is to be removed before publication ]]
This draft is built from markdown source, and its development is
tracked in a git repository (https://gitlab.com/dkg/lamps-header-
protection).
While minor editorial suggestions and nit-picks can be made as merge
requests (https://gitlab.com/dkg/lamps-header-protection), please
direct all substantive discussion to the LAMPS mailing list
(https://www.ietf.org/mailman/listinfo/spasm) at "spasm@ietf.org".
Appendix E. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]
* draft-ietf-lamps-header-protection-03
- dkg takes over from Bernie as primary author
- Add Usability section
- describe two distinct formats "Wrapped Message" and "Injected
Headers"
- Introduce Header Confidentiality Policy model
- Overhaul message composition guidance
- Simplify document creation workflow, move public face to gitlab
* draft-ietf-lamps-header-protection-02 * draft-ietf-lamps-header-protection-02
- editorial changes / improve language - editorial changes / improve language
* draft-ietf-lamps-header-protection-01 * draft-ietf-lamps-header-protection-01
- Add DKG as co-author - Add DKG as co-author
- Partial Rewrite of Abstract and Introduction [HB/AM/DKG] - Partial Rewrite of Abstract and Introduction [HB/AM/DKG]
- Adding definiations for Cryptographic Layer, Cryptographic - Adding definiations for Cryptographic Layer, Cryptographic
Payload, and Cryptographic Envelope (reference to Payload, and Cryptographic Envelope (reference to
skipping to change at page 26, line 39 skipping to change at page 46, line 19
distinguish between Encrypted and Unencrypted Messages [HB] distinguish between Encrypted and Unencrypted Messages [HB]
- Removed (commented out) Header Field Flow Figure (it appeared - Removed (commented out) Header Field Flow Figure (it appeared
to be confusing as is was) [HB] to be confusing as is was) [HB]
* draft-ietf-lamps-header-protection-00 * draft-ietf-lamps-header-protection-00
- Initial version (text partially taken over from - Initial version (text partially taken over from
[I-D.ietf-lamps-header-protection-requirements] [I-D.ietf-lamps-header-protection-requirements]
Appendix D. Open Issues Appendix F. Open Issues
[[ RFC Editor: This section should be empty and is to be removed [[ RFC Editor: This section should be empty and is to be removed
before publication. ]] before publication. ]]
* Ensure "protected header" (Ex-Memory-Hole) option is (fully) * Ensure "protected header" (Ex-Memory-Hole) option is (fully)
compliant with the MIME standard, in particular also [RFC2046], compliant with the MIME standard, in particular also [RFC2046],
Section 5.1. (Multipart Media Type) Appendix B.1.1.1. Section 5.1. (Multipart Media Type) Appendix C.1.1.1.
* More examples (e.g. in Section 4.1.2.5) * Test Vectors! This should be a new appendix section, to avoid
injecting large blobs of unreadable data in the main text. Once
present, we can point to the relevant test vector in the main text
by reference.
* Should Outer Message Header Section (as received) be preserved for * Should Outer Message Header Section (as received) be preserved for
the user? (Section 4.1.3.2.2) the user? (Section 4.1.4.5)
* Decide on whether or not merge requirements from * Decide on whether or not merge requirements from
[I-D.ietf-lamps-header-protection-requirements] into this [I-D.ietf-lamps-header-protection-requirements] into this
document. document.
* Decide what parts of [I-D.autocrypt-lamps-protected-headers] to * Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
merge into this document. merge into this document.
* Enhance Introduction Section 1 and Problem Statement (Section 2). * Enhance Introduction Section 1 and Problem Statement (Section 2).
skipping to change at page 27, line 29 skipping to change at page 47, line 12
paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1 paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1
accordingly. accordingly.
* Verify ability to distinguish between Messages with Header * Verify ability to distinguish between Messages with Header
Protection as specified in this document and legacy clients and Protection as specified in this document and legacy clients and
update Section 3.1 accordingly. update Section 3.1 accordingly.
* Improve definitions of Protection Levels and enhance list of * Improve definitions of Protection Levels and enhance list of
Protection Levels (Section 3.2, Section 4). Protection Levels (Section 3.2, Section 4).
* Privacy Considerations Section 6 * Privacy Considerations Section 7
* Security Considerations Section 5 * Security Considerations Section 6
Authors' Addresses Authors' Addresses
Daniel Kahn Gillmor
American Civil Liberties Union
125 Broad St.
New York, NY, 10004
United States of America
Email: dkg@fifthhorseman.net
Bernie Hoeneisen Bernie Hoeneisen
pEp Foundation pEp Foundation
Oberer Graben 4 Oberer Graben 4
CH- CH-8400 Winterthur CH- CH-8400 Winterthur
Switzerland Switzerland
Email: bernie.hoeneisen@pep.foundation Email: bernie.hoeneisen@pep.foundation
URI: https://pep.foundation/ URI: https://pep.foundation/
Daniel Kahn Gillmor
American Civil Liberties Union
125 Broad St.
New York, NY, 10004
United States of America
Email: dkg@fifthhorseman.net
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex Hampton, Middlesex
TW12 2NP TW12 2NP
United Kingdom United Kingdom
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
 End of changes. 129 change blocks. 
291 lines changed or deleted 1167 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/