draft-ietf-lamps-header-protection-requirements-00.txt   draft-ietf-lamps-header-protection-requirements-01.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Informational B. Hoeneisen Intended status: Informational B. Hoeneisen
Expires: January 9, 2020 Ucom.ch Expires: April 30, 2020 Ucom.ch
July 08, 2019 October 28, 2019
Problem Statement and Requirements for Header Protection Problem Statement and Requirements for Header Protection
draft-ietf-lamps-header-protection-requirements-00 draft-ietf-lamps-header-protection-requirements-01
Abstract Abstract
Privacy and security issues with email header protection in S/MIME Privacy and security issues with email header protection in S/MIME
have been identified for some time. However, the desire to fix these have been identified for some time. However, the desire to fix these
issue has been expressed in the IETF LAMPS Working Group only issues has only recently been expressed in the IETF LAMPS Working
recently. The existing S/MIME specification is likely to be updated Group. The existing S/MIME specification is likely to be updated
regarding header protection. regarding header protection.
Several LAMPS WG participants expressed the opinion that whatever
mechanism will be chosen, it should not be limited to S/MIME, but
also applicable to PGP/MIME.
This document describes the problem statement, generic use cases, and This document describes the problem statement, generic use cases, and
requirements. Additionally it drafts possible solutions to address requirements of header protection.
the challenge. Finally some best practices are collected.
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.
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 January 9, 2020. This Internet-Draft will expire on April 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6 3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . 6 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Sending Side . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 7 4.1.2. Receiving Side . . . . . . . . . . . . . . . . . . . 8
4.2. Additional Requirements for Backward-Compatibility With 4.2. Additional Requirements for Backward-Compatibility With
Legacy Clients Unaware of Header Protection . . . . . . . 8 Legacy Clients Unaware of Header Protection . . . . . . . 8
4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Sending side . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 8 4.2.2. Receiving side . . . . . . . . . . . . . . . . . . . 9
4.3. Additional Requirements for Backward-Compatibility with 4.3. Additional Requirements for Backward-Compatibility with
Legacy Header Protection Systems (if supported) . . . . . 8 Legacy Header Protection Systems (if supported) . . . . . 9
4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9 4.3.1. Sending Side . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9 4.3.2. Receiving Side . . . . . . . . . . . . . . . . . . . 9
5. Options to Achieve Header Protection . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Option 1: Memory Hole . . . . . . . . . . . . . . . . . . 9 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
5.2. Option 2: Wrapping with message/rfc822 or message/global 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Content-Type Parameter "forwarded" . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Option 2.1: Progressive Header Disclosure . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.4.1. Option 1: Memory Hole . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 11
5.4.2. Option 2: Wrapping with message/rfc822 or Appendix A. Implementation Considerations . . . . . . . . . . . 12
message/global . . . . . . . . . . . . . . . . . . . 13 A.1. Options to Achieve Header Protection . . . . . . . . . . 12
5.4.3. Option 2.1 Progressive Header Disclosure . . . . . . 14 A.1.1. Option 1: Memory Hole . . . . . . . . . . . . . . . . 12
6. Sending Side Considerations . . . . . . . . . . . . . . . . . 14 A.1.2. Option 2: Wrapping with message/rfc822 or
6.1. Candidate Header Fields for Header Protection . . . . . . 14 message/global . . . . . . . . . . . . . . . . . . . 12
7. Receiving Side Considerations . . . . . . . . . . . . . . . . 16 A.1.3. Option 2.1: Progressive Header Disclosure . . . . . . 13
7.1. Which Header Fields to Display to User . . . . . . . . . 16 A.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Mail User Agent Algorithm for deciding which version of a A.2. Sending Side Considerations . . . . . . . . . . . . . . . 20
header field to display . . . . . . . . . . . . . . . . . 16 A.2.1. Candidate Header Fields for Header Protection . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 A.3. Receiving Side Considerations . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 A.3.1. Which Header Fields to Display to User . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 A.3.2. Mail User Agent Algorithm for deciding which version
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 of a header field to display . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 18
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[[ Note: Please be advised that this document is early work-in-
progress, and will substantially change in future revisions. ]]
A range of protocols for the protection of electronic mail (email) A range of protocols for the protection of electronic mail (email)
exist, which allow to assess the authenticity and integrity of the exist, which allow to assess the authenticity and integrity of the
email headers section or selected header fields from the domain-level email headers section or selected header fields (HF) from the domain-
perspective, specifically DomainKeys Identified Mail (DKIM) [RFC6376] level perspective, specifically DomainKeys Identified Mail (DKIM)
and Sender Policy Framework (SPF) [RFC7208] and Domain-based Message [RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
Authentication, Reporting, and Conformance (DMARC) [RFC7489]. These based Message Authentication, Reporting, and Conformance (DMARC)
protocols, while essential to responding to a range of attacks on [RFC7489]. These protocols, while essential to responding to a range
email, do not offer full end-to-end protection to the headers section of attacks on email, do not offer full end-to-end protection to the
and are not capable of providing privacy for the information header section and are not capable of providing privacy for the
contained therein. information contained therein.
The need for means of Data Minimization, which includes data The need for means of Data Minimization, which includes data
spareness and the hiding of all technically concealable information spareness and hiding all technically concealable information whenever
whenever possible, has grown in importance over the past years. possible, has grown in importance over the past several years.
A standard for end-to-end protection of the email headers section A standard for end-to-end protection of the email header section
exists for S/MIME since version 3.1. (cf. [RFC8551]): exists for S/MIME version 3.1 and later. (cf. [RFC8551]):
In order to protect outer, non-content-related message header In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc" fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services message/rfc822 wrapper in order to apply S/MIME security services
to these header fields. to these header fields.
No mechanism for header protection has been standardized for PGP No mechanism for header protection (HP) has been standardized for PGP
(Pretty Good Privacy) yet. (Pretty Good Privacy) [RFC4880] yet.
End-to-end protection for the email headers section is currently not Several varying implementations of end-to-end protections for email
widely implemented - neither for messages protected by means of header sections exist, though the total number of such
S/MIME nor PGP. At least two variants of header protection are known implementations appears to be rather low.
to be implemented.
This document describes the problem statement, generic use cases Some LAMPS WG participants expressed the opinion that whatever
(Section 3) and requirements for header protection (Section 4). mechanism will be chosen, it should not be limited to S/MIME, but
Additionally it drafts possible solutions to address the challenge. also applicable to PGP/MIME.
However, the final solution will be determined by the IETF LAMPS WG.
Finally, some best practices are collected.
[[ TODO: enhance this section ]] This document describes the problem statement (Section 2), generic
use cases (Section 3) and requirements for Header Protection
(Section 4). In Appendix A, possible solutions to address the
challenge and some best practices are collected. In any case, the
final solution is to be determined by the IETF LAMPS WG.
1.1. Requirements Language 1.1. 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.2. Terms 1.2. Terms
The following terms are defined for the scope of this document: The following terms are defined for the scope of this document:
o Header Field:: cf. [RFC5322] o Header Protection (HP): cryptographic protection of email Header
Sections for signatures and encryption
o Header Section: cf. [RFC5322] o Header Field (HF): cf. [RFC5322]
o Signed-only message: a multipart/signed or application/pkcs7-mime o Header Section (HS): cf. [RFC5322]
containing SignedData message which doesn't contain any encrypted
layer. I.e. this is a message which is not encrypted and not
encrypted + signed.
o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A o 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."
o 'Signature and encryption', 'signature only' or 'encryption only'
are further explained in Section 3.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.
[[ TODO: enhance this section ]] In the following a set of challenges to be addressed:
[[ TODO: enhance this section, add more items to the following ]]
2.1. Privacy
o Data Minimization, which includes data spareness and hiding all
technically concealable information whenever possible
2.2. Security
o MITM attacks (cf. [RFC4949])
2.3. Usability
o User interaction / User experience
2.4. Interoperability
o Interoperability with [RFC8551] implementations
3. Use Cases 3. Use Cases
In the following, we show the generic use cases that need to be In the following a list of the generic use cases that need to be
addressed independently of whether S/MIME, PGP/MIME or any other addressed for messages with Header Protection (HP). These use cases
technology is used for which Header Protection (HP) is to be applied apply independently of whether S/MIME, PGP/MIME or any other
to. technology is used to achieve HP.
3.1. Interactions 3.1. Interactions
The main interaction case for Header Protection (HP) is: The main interaction case for Header Protection (HP) is:
1) Both peers (sending and receiving side) fully support HP 1) Both peers (sending and receiving side) fully support HP
For backward compatibility of legacy clients - unaware of any HP - For backward compatibility of legacy clients - unaware of any HP -
the following intermediate interactions need to be considered as the following intermediate interactions need to be considered as
well: well:
2) The sending side fully supports HP, while the receiving side does 2) The sending side fully supports HP, while the receiving side does
not support any HP not support any HP
3) The sending side does not support any HP, while the receiving 3) The sending side does not support any HP, while the receiving
side fully supports HP (trivial case) side fully supports HP
4) Neither the sending side nor the receiving side supports any HP 4) Neither the sending side nor the receiving side supports any HP
(trivial case) (trivial case)
The following intermediate use cases may need to be considered as The following intermediate use cases may need to be considered as
well for backward compatibility with legacy HP systems, such as well for backward compatibility with legacy HP systems, such as
S/MIME since version 3.1 (cf. [RFC8551]), in the following S/MIME version 3.1 and later (cf. [RFC8551]), in the following
designated as legacy HP: designated as legacy HP:
5) The sending side fully supports HP, while the receiving side 5) The sending side fully supports HP, while the receiving side
supports legacy HP only supports legacy HP only
6) The sending side supports legacy HP only, while the receiving side 6) The sending side supports legacy HP only, while the receiving side
fully supports HP fully supports HP
7) Both peers (sending and receiving side) support legacy HP only 7) Both peers (sending and receiving side) support legacy HP only
8) The sending side supports legacy HP only, while the receiving side 8) The sending side supports legacy HP only, while the receiving side
does not support any HP does not support any HP
9) The sending side does not support any HP, while the receiving side 9) The sending side does not support any HP, while the receiving side
supports legacy HP only (trivial case) supports legacy HP only
Note: It is to be decided whether to ensure legacy HP systems do not Note: It is to be decided whether to ensure legacy HP systems do not
conflict with any new solution for HP at all or whether (and to which conflict with any new solution for HP at all or whether (and to which
degree) backward compatibility to legacy HP systems shall be degree) backward compatibility to legacy HP systems shall be
maintained. maintained.
[[ TODO: Decide in which form legacy HP requirements should remain in [[ TODO: Decide in which form legacy HP requirements should remain in
this document. ]] this document. ]]
3.2. Protection Levels 3.2. Protection Levels
The following protection levels need to be considered: The following protection levels need to be considered:
a) signature and encryption a) Signature and encryption
b) signature only Messages containing a cryptographic signature which are also
encrypted.
c) encryption only [[ TODO: verify whether relevant ]] Sending and receiving side SHOULD implement 'signature and
encryption', which is the default to use on the sending side.
b) Signature only
Messages containing a cryptographic signature, but which no
encryption is applied to.
Certain implementations MAY decide to send 'signature only' messages,
depending on the circumstances and customer requirements. Sending
and Receiving sides SHOULD implement 'signature only'.
c) Encryption only
Messages that encryption is applied to which do not contain a
cryptographic signature.
'Encryption only' is NOT RECOMMENDED on the sending side, however the
receiving side needs certain guidelines on how to process received
'encrypted only' messages
4. Requirements 4. Requirements
In the following a list of requirements that need to be addressed The following is a list of requirements that need to be addressed
independently of whether S/MIME, PGP/MIME or any other technology is independently of whether S/MIME, PGP/MIME or any other technology is
used to apply HP to. used to apply HP to.
4.1. General Requirements 4.1. General Requirements
This subsection is listing the requirements to address use case 1) Note: This subsection lists the requirements to address use case 1)
(cf. Section 3.1). (cf. Section 3.1).
G1: Define the format for HP for all protection levels MIME G1: Define the HP format for all protection levels (cf. above), which
structure, Content-Type (including all parameters, such as includes MIME structure, Content-Type (including all parameters,
"charset" and "name"), Content-Disposition (including all such as "charset" and "name"), Content-Disposition (including all
parameters, such as "filename"), and Content-Transfer-Encoding. parameters, such as "filename"), and Content-Transfer-Encoding.
G2: To foster wide implementation of the new solution, it shall be G2: To foster wide implementation of the new solution, it shall be
easily implementable. Unless needed for maximizing protection and easily implementable. Unless needed for maximizing protection and
privacy, existing implementations shall not require substantial privacy, existing implementations shall not require substantial
changes in the existing code base. In particular also MIME changes in the existing code base. In particular also MIME
libraries widely used shall not need to be changed to comply with libraries widely used shall not need to be changed to comply with
the new mechanism for HP. the new mechanism for HP.
G3: There SHOULD be only one format that covers all Protection Levels G3: There SHOULD be a single format that covers all protection levels
(cf. {{protection-levels}})) (cf. above).
[[ TODO: Should this one remain in the document? [[ TODO: Should this one remain in the document?]]
If yes, consider improve / rewrite sentence
]]
G4: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in G4: Ensure that man-in-the-middle attack (MITM, cf. [RFC4949]), in
particular downgrade attacks, are mitigated as good as possible. particular downgrade attacks, are mitigated to the greatest extent
possible.
4.1.1. Sending Side 4.1.1. Sending Side
GS1: Determine which Header Fields (HFs) should or must be protected GS1: Determine which Header Fields (HFs) should or must be protected
at least for signed only email. for 'signature only' emails at a minimum.
GS2: Determine which HFs should or must be sent in clear of an GS2: Determine which HFs should or must be sent in clear text (i.e.,
encrypted email. included in the outer header) for emails with (signature and)
encryption applied.
GS3: Determine which HF should not or must not be included in the GS3: Determine which HFs should not or must not be sent in clear text
visible header (for transport) of an encrypted email, with the (i.e., not be included in the outer header) of an email with
default being that whatever is not needed from GS2 is not put (signature and) encryption applied.
into the unencrypted transport headers, thus fulfilling data
minimization requirements (including data spareness and hiding
of all information that technically can be hidden).
GS4: Determine which HF to not to include to any HP part (e.g. Bcc). GS4: Determine which HFs to not include to any HP part (e.g. Bcc).
4.1.2. Receiving Side 4.1.2. Receiving Side
GR1: Determine how HF should be displayed to the user in case of
GR1: Determine how HFs should be displayed to the user in case of
conflicting information between the protected and unprotected conflicting information between the protected and unprotected
headers. HFs.
GR2: Ensure that man-in-the-middle attack (MITM) cf. {{RFC4949}}, in GR2: Ensure that man-in-the-middle attacks (MITM, cf. [RFC4949]), in
particular downgrade attacks, can be detected. particular downgrade attacks, can be detected.
GR3: Define how emails that 'encryption only' was applied to
are to be treated.
4.2. Additional Requirements for Backward-Compatibility With Legacy 4.2. Additional Requirements for Backward-Compatibility With Legacy
Clients Unaware of Header Protection Clients Unaware of Header Protection
This sub-section addresses the use cases 2) - 4) (cf. Section 3.1) Note: This sub-section addresses the use cases 2) - 4) (cf.
Section 3.1)
B1: Depending on the solution, define a means to distinguish between B1: Define a means to distinguish between forwarded emails and
forwarded messages and encapsulated messages using new HP encapsulated emails using new HP mechanism.
mechanism.
4.2.1. Sending side 4.2.1. Sending side
BS1: Define how full HP support can be indicated to outgoing BS1: Define how full HP support can be indicated to outgoing
messages. emails.
BS2: Define how full HP support of the receiver can be detected or BS2: Define how full HP support of the receiver can be detected or
guessed. derived.
BS3: Ensure a HP unaware receiving side easily can display the BS3: Ensure a HP-unaware receiving side easily can display the
"Subject" HF to the user. "Subject" HF to the user.
4.2.2. Receiving side 4.2.2. Receiving side
BR1: Define how full HP support can be detected in incoming messages. BR1: Define how full HP support can be detected in incoming emails.
4.3. Additional Requirements for Backward-Compatibility with Legacy 4.3. Additional Requirements for Backward-Compatibility with Legacy
Header Protection Systems (if supported) Header Protection Systems (if supported)
This sub-section addresses the use cases 5) - 9) (cf. Section 3.1). Note: This sub-section addresses the use cases 5) - 9) (cf.
Section 3.1).
LS1: Depending on the solution, define a means to distinguish between LS1: Depending on the solution, define a means to distinguish between
forwarded messages, legacy encapsulated messages, and forwarded emails, legacy encapsulated emails, and
encapsulated messages using new HP mechanism. encapsulated emails using new HP mechanism.
LS2: The solution should be backward compatible to existing solutions LS2: The solution should be backward compatible to existing solutions
and aim to minimize the implementation effort to include support and aim to minimize the implementation effort to include support
for existing solutions. for existing solutions.
4.3.1. Sending Side 4.3.1. Sending Side
LSS1: Determine how legacy HP support can be indicated to outgoing LSS1: Determine how legacy HP support can be indicated to outgoing
messages. emails.
LSS2: Determine how legacy HP support of the receiver can be detected LSS2: Determine how legacy HP support of the receiver can be detected
or guessed. or derived.
4.3.2. Receiving Side 4.3.2. Receiving Side
LSR1: Determine how legacy HP support can be detected in incoming LSR1: Determine how legacy HP support can be detected in incoming
messages. emails.
5. Options to Achieve Header Protection 5. Security Considerations
In the following a set of Options to achieve Email Header Protection. This document talks about UI considerations, including security
It is expected that the IETF LAMPS WG chooses an option to update considerations, when processing messages protecting Header Fields.
[RFC8551] wrt. Header Protection. One of the goals of this document is to specify UI for displaying
such messages which is less confusing/misleading for the end-user and
thus more secure.
5.1. Option 1: Memory Hole The document does not define a new protocol, and thus does not create
any new security concerns not already covered by S/MIME [RFC8551],
MIME [RFC2045] and Email [RFC5322] in general.
Memory Hole approach works by copying the normal message header 6. Privacy Considerations
[[ TODO ]]
7. IANA Considerations
This document requests no action from IANA.
[[ RFC Editor: This section may be removed before publication. ]]
8. Acknowledgments
The authors would like to thank the following people who have
provided helpful comments and suggestions for this document: David
Wilson, Kelly Bristol, Robert Williams, Steve Kille, and Wei Chuang.
Essential parts of [I-D.luck-lamps-pep-header-protection] have been
merged into this document. Special thanks to its author Claudio
Luck. For further Acknowledgments, please refer to Acknowledgments
section of [I-D.luck-lamps-pep-header-protection].
David Wilson came up with the idea of defining a new Content-Type
header field parameter to distinguish forwarded messages from inner
header field protection constructs.
9. References
9.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
9.2. Informative References
[I-D.luck-lamps-pep-header-protection]
Luck, C., "pretty Easy privacy (pEp): Progressive Header
Disclosure", draft-luck-lamps-pep-header-protection-03
(work in progress), July 2019.
[I-D.marques-pep-email]
Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", draft-marques-pep-email-02 (work in progress),
October 2018.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[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>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
Appendix A. Implementation Considerations
[[ Note: Please be advised that this part of the document is early
work-in-progress. ]]
This Appendix A contains additional information and considerations
regarding the implementation. Although not (strictly) part of the
requirements, this is useful to better understand them. Parts of the
text in this Appendix A will likely be moved to the upcoming
implementation document.
A.1. Options to Achieve Header Protection
The following are current options for addressing Email Header
Protection. The IETF LAMPS WG may choose from these options in order
to update [RFC8551].
A.1.1. Option 1: Memory Hole
The Memory Hole approach works by copying the normal message header
fields into the MIME header section of the top level protected body fields into the MIME header section of the top level protected body
part. Since the MIME body part header section is itself covered by part. Since the MIME body part header section is itself covered by
the protection mechanisms (signing and/or encryption) it shares the the protection mechanisms (signature and/or encryption) it shares the
protections of the message body. protections of the message body.
[[ TODO: add more information on memory hole ]] [[ TODO: add more information on memory hole ]]
5.2. Option 2: Wrapping with message/rfc822 or message/global A.1.2. Option 2: Wrapping with message/rfc822 or message/global
Wrapping with message/rfc822 (or message/global) works by copying the Wrapping with message/rfc822 (or message/global) works by copying the
normal message header fields into the MIME header section of the top normal message header fields into the MIME header section of the top
level protect body part level protect body part
[[ TODO: consider rephrasing, as not only the header fields is [[ TODO: consider rephrasing, as not only the header fields is
copied, but also the content.]] copied, but also the content.]]
and then prepending them with "Content-Type: message/rfc822; and then prepending them with "Content-Type: message/rfc822;
forwarded=no\r\n" or "Content-Type: message/global; forwarded=no\r\n" or "Content-Type: message/global;
forwarded=no\r\n", where \r\n is US-ASCII CR followed by US-ASCII LF. forwarded=no\r\n", where \r\n is US-ASCII CR followed by US-ASCII LF
Since the MIME body part header section is itself covered by the (see also Appendix A.1.2.1). Since the MIME body part header section
protection mechanisms (signing and/or encryption) it shares the is itself covered by the protection mechanisms (signature and/or
protections of the message body. encryption) it shares the protections of the message body.
5.2.1. Content-Type Parameter "forwarded" A.1.2.1. Content-Type Parameter "forwarded"
This section outlines how the new "forwarded" Content-Type header This section outlines how the new "forwarded" Content-Type header
field parameter could be defined (probably in a separate document) field parameter could be defined (probably in a separate document)
and how header section wrapping works: and how header section wrapping works:
This document defines a new Content-Type header field parameter This document defines a new Content-Type header field parameter
[RFC2045] with name "forwarded". The parameter value is case- [RFC2045] with name "forwarded". The parameter value is case-
insensitive and can be either "yes" or "no". (The default value insensitive and can be either "yes" or "no". (The default value
being "yes"). The parameter is only meaningful with media type being "yes"). The parameter is only meaningful with media type
"message/rfc822" and "message/global" [RFC6532] when used within "message/rfc822" and "message/global" [RFC6532] when used within
S/MIME signed or encrypted body parts. The value "yes" means that S/MIME or PGP/MIME signed or encrypted body parts. The value "yes"
the message nested inside "message/rfc822" ("message/global") is a means that the message nested inside "message/rfc822" ("message/
forwarded message and not a construct created solely to protect the global") is a forwarded message and not a construct created solely to
inner header section. protect the inner header section.
Instructions in [RFC8551] describing how to protect the Email message Instructions in [RFC8551] describing how to protect the Email message
header section [RFC5322], by wrapping the message inside a message/ header section [RFC5322], by wrapping the message inside a message/
rfc822 container [RFC2045] are thus updated to read: rfc822 container [RFC2045] are thus updated to read:
In order to protect outer, non-content-related message header In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc" fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security services message/rfc822 wrapper in order to apply S/MIME security services
to these header fields. It is up to the receiving client to to these header fields. It is up to the receiving client to
skipping to change at page 10, line 41 skipping to change at page 13, line 35
unprotected "outer" header section. unprotected "outer" header section.
When an S/MIME message is received, if the top-level protected When an S/MIME message is received, if the top-level protected
MIME entity has a Content-Type of message/rfc822 or message/global MIME entity has a Content-Type of message/rfc822 or message/global
without the "forwarded" parameter or with the "forwarded" without the "forwarded" parameter or with the "forwarded"
parameter set to "no", it can be assumed that the intent was to parameter set to "no", it can be assumed that the intent was to
provide header protection. This entity SHOULD be presented as the provide header protection. This entity SHOULD be presented as the
top-level message, taking into account header section merging top-level message, taking into account header section merging
issues as previously discussed. issues as previously discussed.
5.3. Option 2.1: Progressive Header Disclosure A.1.3. Option 2.1: Progressive Header Disclosure
This option is similar to Option 2 (cf. Section 5.2). It also makes This option is similar to Option 2 (cf. Appendix A.1.2). It also
use the Content-Type parameter "forwarded" (cf. Section 5.2.1). makes use the Content-Type parameter "forwarded" (cf.
Appendix A.1.2.1).
pEp for email [I-D.marques-pep-email] defines a fixed MIME structure pEp for email [I-D.marques-pep-email] defines a fixed MIME structure
for its innermost message structure. Security comes just next after for its innermost message structure. Security comes just next after
privacy in pEp, for which reason the application of signatures privacy in pEp, for which reason the application of signatures
without encryption to messages in transit is not considered without encryption to messages in transit is not considered
purposeful. pEp for email, either expects to transfer messages in purposeful. pEp for email, either expects to transfer messages in
cleartext without signature or encryption, or transfer them encrypted cleartext without signature or encryption, or transfer them encrypted
and with enclosed signature and necessary public keys so that replies and with enclosed signature and necessary public keys so that replies
can be immediately upgraded to encrypted messages. can be immediately upgraded to encrypted messages.
The pEp message format is equivalent to the S/MIME standard in The pEp message format is equivalent to the S/MIME standard in
ensuring header protection, in that the whole message is protected ensuring header protection, in that the whole message is protected
instead, by wrapping it and providing cryptographic services to the instead, by wrapping it and providing cryptographic services to the
whole original message. However, for the purpose of allowing the whole original message. However, for the purpose of allowing the
insertion of public keys, the root entity of the protected message is insertion of public keys, the root entity of the protected message is
thus nested once more into an additional multipart/mixed MIME entity. thus nested once more into an additional multipart/mixed MIME entity.
The current pEp proposal is for PGP/MIME, while an extension to The current pEp proposal is for PGP/MIME, while an extension to
S/MIME is also on the roadmap. S/MIME is also on the roadmap.
pEp has also implemented the above (in Section 5.2.1) described pEp has also implemented the above (in Appendix A.1.2.1) described
Content-Type parameter "forwarded" to distinguish between Content-Type parameter "forwarded" to distinguish between
encapsulated and forwarded emails. encapsulated and forwarded emails.
More information on progressive header disclosure can be found in More information on progressive header disclosure can be found in
[I-D.luck-lamps-pep-header-protection]. [I-D.luck-lamps-pep-header-protection].
5.4. Examples A.1.4. Examples
Examples in subsequent sections assume that an email client is trying Examples in subsequent sections assume that an email client is trying
to protect (sign) the following initial message: to protect (sign) the following initial message:
Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
From: "Alexey Melnikov" <alexey.melnikov@example.net> From: "Alexey Melnikov" <alexey.melnikov@example.net>
Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net> Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
MIME-Version: 1.0 MIME-Version: 1.0
MMHS-Primary-Precedence: 3 MMHS-Primary-Precedence: 3
Subject: Meeting at my place Subject: Meeting at my place
skipping to change at page 12, line 26 skipping to change at page 15, line 26
Without message header protection the corresponding signed message Without message header protection the corresponding signed message
might look like this. (Lines prepended by "O: " are the outer might look like this. (Lines prepended by "O: " are the outer
header.) header.)
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net> O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
O: Subject: Meeting at my place O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net> O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: MIME-Version: 1.0 O: MIME-Version: 1.0
O: content-type: multipart/signed; charset=us-ascii; micalg=sha1; O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature"; O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format. This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237 --.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified. This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237 --.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
content-type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[[base-64 encoded signature]] [[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237-- --.cbe16d2a-e1a3-4220-b821-38348fc97237--
5.4.1. Option 1: Memory Hole A.1.4.1. Option 1: Memory Hole
The following example demonstrates how header section and payload of The following example demonstrates how header section and payload of
a protect body part might look like. For example, this will be the a protect body part might look like. For example, this will be the
first body part of a multipart/signed message or the signed and/or first body part of a multipart/signed message or the signed and/or
encrypted payload of the application/pkcs7-mime body part. Lines encrypted payload of the application/pkcs7-mime body part. Lines
prepended by "O: " are the outer header section. Lines prepended by prepended by "O: " are the outer header section. Lines prepended by
"I: " are the inner header section. "I: " are the inner header section.
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net> O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
O: Subject: Meeting at my place O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net> O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: MIME-Version: 1.0 O: MIME-Version: 1.0
O: content-type: multipart/signed; charset=us-ascii; micalg=sha1; O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature"; O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format. This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237 --.cbe16d2a-e1a3-4220-b821-38348fc97237
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" <alexey.melnikov@example.net> I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net> I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
I: MIME-Version: 1.0 I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3 I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place I: Subject: Meeting at my place
I: To: somebody@example.net I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified. This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237 --.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
content-type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[[base-64 encoded signature]] [[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237-- --.cbe16d2a-e1a3-4220-b821-38348fc97237--
5.4.2. Option 2: Wrapping with message/rfc822 or message/global [[ TODO (AM): HB: Not sure whether the Outer Subject HF is replaced
by "Encrypted Message" (or alike). Please verify. ]]
A.1.4.2. Option 2: Wrapping with message/rfc822 or message/global
The following example demonstrates how header section and payload of The following example demonstrates how header section and payload of
a protect body part might look like. For example, this will be the a protect body part might look like. For example, this will be the
first body part of a multipart/signed message or the signed and/or first body part of a multipart/signed message or the signed and/or
encrypted payload of the application/pkcs7-mime body part. Lines encrypted payload of the application/pkcs7-mime body part. Lines
prepended by "O: " are the outer header section. Lines prepended by prepended by "O: " are the outer header section. Lines prepended by
"I: " are the inner header section. Lines prepended by "W: " are the "I: " are the inner header section. Lines prepended by "W: " are the
wrapper. wrapper.
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net> O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
O: Subject: Meeting at my place O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net> O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: MIME-Version: 1.0 O: MIME-Version: 1.0
O: content-type: multipart/signed; charset=us-ascii; micalg=sha1; O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature"; O: protocol="application/pkcs7-signature";
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
This is a multipart message in MIME format. This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237 --.cbe16d2a-e1a3-4220-b821-38348fc97237
W: Content-Type: message/rfc822; forwarded=no W: Content-Type: message/rfc822; forwarded=no
W: W:
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" <alexey.melnikov@example.net> I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net> I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
skipping to change at page 14, line 32 skipping to change at page 17, line 32
I: MMHS-Primary-Precedence: 3 I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place I: Subject: Meeting at my place
I: To: somebody@example.net I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified. This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237 --.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
content-type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[[base-64 encoded signature]] [[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237-- --.cbe16d2a-e1a3-4220-b821-38348fc97237--
5.4.3. Option 2.1 Progressive Header Disclosure A.1.4.3. Option 2.1 Progressive Header Disclosure
This looks similar as in option 2. Specific examples can be found in The following example demonstrates how header section and payload of
a protect body part might look like. For example, this will be the
first body part of a multipart/signed message or the signed and
encrypted payload of the application/pkcs7-mime body part. Lines
prepended by "O: " are the outer header section. Lines prepended by
"I: " are the inner header section. Lines prepended by "W: " are the
wrapper.
The main difference compared to Option 2 is an additional multipart/
mixed Content-Type containing the original message (as a whole) and
the public key (of the sender).
Note: This example is derived from the pEp's PGP/MIME implementation
and adjusted to the above S/MIME examples. The pEp implementations
do not support S/MIME yet; therefore the following can serve no more
as for illustrative purpose. Specific examples can be found in
[I-D.luck-lamps-pep-header-protection]. [I-D.luck-lamps-pep-header-protection].
[[ TODO: include an example of the same style. ]] O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
W: MIME-Version: 1.0
W: Content-Type: multipart/mixed;
W: boundary="6b8b4567327b23c6643c986966334873"
W:
W: --6b8b4567327b23c6643c986966334873
W: Content-Type: message/rfc822; forwarded="no"
W:
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
I: Subject: Meeting at my place
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
I: MIME-Version: 1.0
I: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
I: protocol="application/pkcs7-signature";
I: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
6. Sending Side Considerations This is a multipart message in MIME format.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Type: text/plain; charset=us-ascii
6.1. Candidate Header Fields for Header Protection This is an important message that I don't want to be modified.
--.cbe16d2a-e1a3-4220-b821-38348fc97237
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
[[base-64 encoded signature]]
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
W: --6b8b4567327b23c6643c986966334873
W: Content-Type: application/pgp-keys
W: Content-Disposition: attachment; filename="pEpkey.asc"
W:
-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----
W:
W: --6b8b4567327b23c6643c986966334873--
A.2. Sending Side Considerations
A.2.1. Candidate Header Fields for Header Protection
[[ TODO: This section is very early stage and needs more work. ]] [[ TODO: This section is very early stage and needs more work. ]]
For a signed-only message, it is RECOMMENDED that all "outer" header
fields are identical to the "inner" protected header fields. This For a 'signature only' (cf. Section 3.2) message, it is RECOMMENDED
would mean that all header fields are signed. In this case, the that all "outer" header fields are identical to the "inner" protected
"outer" header fields simply match the protected header fields. And header fields. This would mean that all header fields are signed.
in the case that the "outer" header fields differ, they can simply be In this case, the "outer" header fields simply match the protected
replaced with their protected versions when displayed to the user. header fields. And in the case that the "outer" header fields
differ, they can simply be replaced with their protected versions
when displayed to the user.
[[ TODO: Decide whether "Bcc" header field should be excluded. Also [[ TODO: Decide whether "Bcc" header field should be excluded. Also
verify whether this requirement applies generally or just for verify whether this requirement applies generally or just for
specific implementations. ]] specific implementations. ]]
When generating encrypted or encrypted+signed S/MIME messages which When generating S/MIME messages with applied (signature and)
protect header fields: encryption to protect header fields:
1. If a header field is being encrypted because it is sensitive, its 1. If a header field is being encrypted because it is sensitive, its
true value MUST NOT be included in the outer header. If the true value MUST NOT be included in the outer header. If the
header field is mandatory according to [RFC5322], a stub value header field is mandatory according to [RFC5322], a stub value
(or a value indicating that the outer value is not to be used) is (or a value indicating that the outer value is not to be used) is
to be included in the outer header section. to be included in the outer header section.
2. The outer header section SHOULD be minimal in order to avoid 2. The outer header section SHOULD be minimal in order to avoid
disclosure of confidential information. It is recommended that disclosure of confidential information. It is recommended that
the outer header section only contains "Date" (set to the same the outer header section only contains "Date" (set to the same
value as in the inner header field, or, if the Date value is also value as in the inner header field, or, if the Date value is also
sensitive, to Monday 9am of the same week), possibly "Subject" sensitive, to Monday 9am of the same week), possibly "Subject"
and "To"/"Bcc" header fields. ("From", "Date", and at least one and "To"/"Cc" header fields. ("From", "Date", and at least one
destination header field is mandatory as per [RFC5322].) In destination header field is mandatory as per [RFC5322].) In
particular, Keywords, In-Reply-To and References header fields particular, Keywords, In-Reply-To and References header fields
SHOULD NOT be included in the outer header; "To" and "Cc" header SHOULD NOT be included in the outer header; "To" and "Cc" header
fields should be omitted and replaced with "Bcc: undisclosed- fields should be omitted and replaced with "Bcc: undisclosed-
recipients;". recipients;".
But note that having key header fields duplicated in the outer But note that having key header fields duplicated in the outer
header is convenient for many message stores (e.g. IMAP) and header is convenient for many message stores (e.g. IMAP) and
clients that can't decode S/MIME encrypted messages. In clients that can't decode S/MIME encrypted messages. In
particular, Subject/To/Cc/Bcc/Date header field values are particular, Subject/To/Cc/Bcc/Date header field values are
skipping to change at page 16, line 7 skipping to change at page 21, line 13
header. header.
3. The "Subject" header field value of the outer header section 3. The "Subject" header field value of the outer header section
SHOULD either be identical to the inner "Subject" header field SHOULD either be identical to the inner "Subject" header field
value, or contain a clear indication that the outer value is not value, or contain a clear indication that the outer value is not
to be used for display (the inner header field value would to be used for display (the inner header field value would
contain the true value). contain the true value).
Note that recommendations listed above typically only apply to non Note that recommendations listed above typically only apply to non
MIME header fields (header fields with names not starting with MIME header fields (header fields with names not starting with
"Content-" prefix), but there are exception, e.g. Content-Language. "Content-" prefix), but there are exceptions, e.g. Content-Language.
Note that the above recommendations can also negatively affect anti- Note that the above recommendations can also negatively affect anti-
spam processing. spam processing.
7. Receiving Side Considerations Messages containing at least one recipient address in the Bcc header
field may appear in up to three different variants:
7.1. Which Header Fields to Display to User 1. The message for the recipient addresses listed in To or Cc header
fields, which must not include the Bcc header field neither for
signature calculation nor for encryption.
When displaying S/MIME messages which protect header fields (whether 2. The message(s) sent to the recipient addresses in the Bcc header
they are signed-only, encrypted or encrypted+signed): field, which depends on the implementation:
a) One message for each recipient in the Bcc header field
separately with a Bcc header field containing only the address of
the recipient it is sent to
b) The same message for each recipient in the Bcc header field
with a Bcc header field containing an indication such as
"Undisclosed recipients" (but no addressees)
c) The same message for each recipient in the Bcc header field
which does not include a Bcc header field (this message is
identical to 1. / cf. above)
3. The message stored in the 'Sent'-Folder of the sender, which
usually contains the Bcc unchanged from the original message,
i.e. with all recipient addresses.
Regarding the Bcc header field there should be no difference between
the inner and the outer header section.
A.3. Receiving Side Considerations
A.3.1. Which Header Fields to Display to User
When displaying S/MIME messages which protect header fields
(independent of which protection level 'signature and encryption',
'signature only' or 'encryption only' is applied to (cf.
Section 3.2):
1. The outer header fields might be tampered with, so a receiving 1. The outer header fields might be tampered with, so a receiving
client SHOULD ignore them, unless they are protected in some client SHOULD ignore them, unless they are protected in some
other way(_). If a header field is present in the inner header, other way(*). If a header field is present in the inner header,
only the inner header field value MUST be displayed (and the only the inner header field value MUST be displayed (and the
corresponding outer value must be ignored). If a particular corresponding outer value must be ignored). If a particular
header field is only present in the outer header, it MAY be header field is only present in the outer header, it MAY be
ignored (not displayed) or it MAY be displayed with a clear ignored (not displayed) or it MAY be displayed with a clear
indicator that it is not trustworthy(_). indicator that it is not trustworthy(*).
(*) - this only applies if the header field is not protected is (*) - this only applies if the header field is not protected is
some other way, for example with a DKIM signature that validates some other way, for example with a DKIM signature that validates
and is trusted. and is trusted.
7.2. Mail User Agent Algorithm for deciding which version of a header A.3.2. Mail User Agent Algorithm for deciding which version of a header
field to display field to display
[[ TODO: describe how to recurse to find the innermost protected root [[ TODO: describe how to recurse to find the innermost protected root
body part, extract header fields from it and propagate them to the body part, extract header fields from it and propagate them to the
top level. This should also work for triple-wrapped messages.]] top level. This should also work for triple-wrapped messages.]]
8. Security Considerations Appendix B. Document Changelog
This document talks about UI considerations, including security
considerations, when processing messages protecting header fields.
One of the goals of this document is to specify UI for displaying
such messages which is less confusing/misleading and thus more
secure.
The document is not defining new protocol, so it doesn't create any
new security concerns not already covered by S/MIME [RFC8551], MIME
[RFC2045] and Email [RFC5322] in general.
9. Privacy Considerations
[[ TODO ]]
10. IANA Considerations
This document requests no action from IANA.
[[ RFC Editor: This section may be removed before publication. ]]
11. Acknowledgments
The authors would like to thank the following people who have
provided helpful comments and suggestions for this document: David
Wilson, Steve Kille, Wei Chuang, and Robert Williams
Essential parts of [I-D.luck-lamps-pep-header-protection] have been
merged into this document. Special thanks to its author Claudio
Luck. For further Acknowledgments, please refer to Acknowledgments
section of [I-D.luck-lamps-pep-header-protection].
David Wilson came up with the idea of defining a new Content-Type
header field parameter to distinguish forwarded messages from inner
header field protection constructs.
12. References
12.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
12.2. Informative References
[I-D.luck-lamps-pep-header-protection]
Luck, C., "pretty Easy privacy (pEp): Progressive Header
Disclosure", draft-luck-lamps-pep-header-protection-03
(work in progress), July 2019.
[I-D.marques-pep-email] [[ RFC Editor: This section is to be removed before publication ]]
Marques, H., "pretty Easy privacy (pEp): Email Formats and
Protocols", draft-marques-pep-email-02 (work in progress),
October 2018.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION o draft-ietf-lamps-header-protection-requirements-00
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", * Initial version
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., o draft-ietf-lamps-header-protection-requirements-01
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized * Moved Implementation Considerations to Appendix (HB)
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for * Shortened abstract (HB)
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based * Many editorial changes, e.g., replaced "content-type" with
Message Authentication, Reporting, and Conformance "Content-Type". (HB)
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
Appendix A. Document Changelog * Added example for Option 2.1 / pEp (HB)
[[ RFC Editor: This section is to be removed before publication ]] * Added (short) definition of Header Protection (HB)
* Added more information regarding Bcc (feedback IETF-105) (HB)
o draft-ietf-lamps-header-protection-requirements-00 * Simplified GS3 (HB)
* Initial version * Added GR3 (HB)
Appendix B. Open Issues Appendix C. 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. ]]
o Enhance Introduction and Problem Statement sections o Enhance Introduction and Problem Statement sections
o Decide in which form legacy HP requirements should remain in this o Decide in which form legacy HP requirements should remain in this
document document
o Signed-only protection needs further study o Improve definitions in Section 3.2
* pEp only does header protection by applying both signing and
encryption. Technically it is also possible to sign, but not
encrypt the protected messages. This needs further study.
Feedback from IETF-104: Probably no need to specify it, but
need to document the case.
o Should requirement G3 remain? If you consider improve / rewrite o Should requirement G3 remain? If you consider improve / rewrite
it. it.
o Add more text on Memory Hole o Add more text on Memory Hole
o Rephrase Section 5.2 o Rephrase Appendix A.1.2
o Add example to Section 5.4.3
o Resolve question regarding Bcc in Section 6.1 o Resolve question regarding Bcc in Appendix A.2.1
o Rewrite Section 6.1 o Rewrite Appendix A.2.1
o Write Section 7.2 o Write Appendix A.3.2
o Correct terminology for Header(s) and Header Fields throughout the o Correct terminology for Header(s) and Header Fields throughout the
document (editorial). document (editorial).
* Header: Whole Header Section of the message * Header: Whole Header Section of the message
* Header Field: Part / single Line inside a Header (Section) * Header Field: Part / single Line inside a Header (Section)
o Replace "email" by "email message" as needed
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
Bernie Hoeneisen Bernie Hoeneisen
 End of changes. 114 change blocks. 
296 lines changed or deleted 451 lines changed or added

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