draft-ietf-lamps-header-protection-07.txt   draft-ietf-lamps-header-protection-08.txt 
LAMPS Working Group D.K. Gillmor LAMPS Working Group D.K. Gillmor
Internet-Draft American Civil Liberties Union Internet-Draft American Civil Liberties Union
Intended status: Standards Track B. Hoeneisen Intended status: Standards Track B. Hoeneisen
Expires: 6 August 2022 pEp Foundation Expires: 8 September 2022 pEp Foundation
A. Melnikov A. Melnikov
Isode Ltd Isode Ltd
2 February 2022 7 March 2022
Header Protection for S/MIME Header Protection for S/MIME
draft-ietf-lamps-header-protection-07 draft-ietf-lamps-header-protection-08
Abstract Abstract
S/MIME version 3.1 has introduced a feasible standardized option to S/MIME version 3.1 introduced a mechanism to provide end-to-end
accomplish Header Protection. However, few implementations generate cryptographic protection of e-mail message headers. However, few
messages using this structure, and several legacy and non-legacy implementations generate messages using this mechanism, and several
implementations have revealed rendering issues at the receiving side. legacy implementations have revealed rendering or security issues
Clearer specifications regarding message processing, particularly when handling such a message.
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 This document updates the S/MIME specification to offer a different
messages with Header Protection, this document updates S/MIME Header mechanism that provides the same cryptographic protections but with
Protection specifications with additional guidance on MIME format, fewer downsides when handled by legacy clients. Furthermore, it
sender and receiver processing. offers more explicit guidance for clients when generating or handling
e-mail messages with cryptographic protection of message headers.
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 6 August 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Two Schemes of Protected Headers . . . . . . . . . . . . 5 1.1. Two Schemes of Header Protection . . . . . . . . . . . . 6
1.2. Problems with Wrapped Messages . . . . . . . . . . . . . 6 1.2. Problems with Wrapped Messages . . . . . . . . . . . . . 6
1.3. Problems with Injected Headers . . . . . . . . . . . . . 6 1.3. Problems with Injected Headers . . . . . . . . . . . . . 7
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Other Protocols to Protect Email Headers . . . . . . . . 7 1.4.1. Backward Compatibility . . . . . . . . . . . . . . . 7
1.6. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.4.2. Deliverability . . . . . . . . . . . . . . . . . . . 8
1.7. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Other Protocols to Protect Email Header Fields . . . . . 8
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 10 1.6. Applicability to PGP/MIME . . . . . . . . . . . . . . . . 9
2.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.7. Requirements Language . . . . . . . . . . . . . . . . . . 9
2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 11 1.8. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 11 1.9. Document Scope . . . . . . . . . . . . . . . . . . . . . 10
2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 11 1.9.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 11
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Interactions . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Injected Headers Scheme . . . . . . . . . . . . . . . . . 12
3.1.1. Main Use Case . . . . . . . . . . . . . . . . . . . . 12 2.2. Wrapped Message Scheme . . . . . . . . . . . . . . . . . 12
3.1.2. Backward Compatibility Use Cases . . . . . . . . . . 12 2.3. Sending Side . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Protection Levels . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Composing a Cryptographically-Protected Message Without
3.2.1. In-Scope . . . . . . . . . . . . . . . . . . . . . . 13 Header Protection . . . . . . . . . . . . . . . . . . 12
3.2.2. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 13 2.3.2. Header Confidentiality Policy . . . . . . . . . . . . 13
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3. Composing with "Injected Headers" Header
4.1. Main Use Case . . . . . . . . . . . . . . . . . . . . . . 14 Protection . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. MIME Format . . . . . . . . . . . . . . . . . . . . . 15 2.3.4. Composing with "Wrapped Message" Header Protection . 18
4.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 17 2.3.5. Choosing Between Wrapped Message and Injected
4.1.3. Default Header Confidentiality Policy . . . . . . . . 23 Headers . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.4. Receiving Side . . . . . . . . . . . . . . . . . . . 24 2.4. Default Header Confidentiality Policy . . . . . . . . . . 19
4.2. Backward Compatibility Use Cases . . . . . . . . . . . . 33 2.4.1. Minimalist Header Confidentiality Policy . . . . . . 20
4.2.1. Receiving Side MIME-Conformant . . . . . . . . . . . 33 2.4.2. Strong Header Confidentiality Policy . . . . . . . . 20
4.2.2. Receiving Side Not MIME-Conformant . . . . . . . . . 33 2.4.3. Offering Stronger Header Confidentiality . . . . . . 20
5. Usability Considerations . . . . . . . . . . . . . . . . . . 34 2.5. Receiving Side . . . . . . . . . . . . . . . . . . . . . 21
5.1. Mixed Protections Within a Message Are Hard To 2.5.1. Identifying that a Message has Header Protection . . 21
Understand . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.2. Updating the Cryptographic Summary . . . . . . . . . 22
2.5.3. Rendering a Message with Injected Headers . . . . . . 22
5.2. Users Should Not Have To Choose a Header Confidentiality 2.5.4. Rendering a Wrapped Message . . . . . . . . . . . . . 25
Policy . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.5. Guidance for Automated Message Handling . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 2.5.6. Affordances for Debugging and Troubleshooting . . . . 28
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 2.5.7. Rendering Other Schemes . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 2.5.8. Composing a Reply to an Encrypted Message with Header
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 Protection . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.9. Implicitly-rendered Header Fields . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 2.5.10. Unprotected Header Fields Added in Transit . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 35 3. E-mail Ecosystem Evolution . . . . . . . . . . . . . . . . . 32
Appendix A. Possible Problems with some Legacy Clients . . . . . 37 3.1. Dropping Legacy Display Elements . . . . . . . . . . . . 32
4. Usability Considerations . . . . . . . . . . . . . . . . . . 32
4.1. Mixed Protections Within a Message Are Hard To
Understand . . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Users Should Not Have To Choose a Header Confidentiality
Policy . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3. Users Should Not Have To Choose a Header Protection
Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Possible Problems with some Legacy Clients . . . . . 35
A.1. Problems Reviewing signed+encrypted Messages in List A.1. Problems Reviewing signed+encrypted Messages in List
View . . . . . . . . . . . . . . . . . . . . . . . . . . 37 View . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. Problems when Rendering a signed+encrypted Message . . . 37 A.2. Problems when Rendering a signed+encrypted Message . . . 36
A.3. Problems when Replying to a signed+encrypted Message . . 38 A.3. Problems when Replying to a signed+encrypted Message . . 37
A.4. Problems Reviewing signed-only Messages in List View . . 39 A.4. Problems Reviewing signed-only Messages in List View . . 37
A.5. Problems when Rendering a signed-only Message . . . . . . 39 A.5. Problems when Rendering a signed-only Message . . . . . . 38
A.6. Problems when Replying to a signed-only Message . . . . . 40 A.6. Problems when Replying to a signed-only Message . . . . . 38
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 39
B.1. Baseline Messages . . . . . . . . . . . . . . . . . . . . 40 B.1. Baseline Messages . . . . . . . . . . . . . . . . . . . . 39
B.1.1. No cryptographic protections over a simple message . 41 B.1.1. No cryptographic protections over a simple message . 39
B.1.2. S/MIME signed-only signedData over a simple message, No B.1.2. S/MIME signed-only signedData over a simple message, No
Header Protection . . . . . . . . . . . . . . . . . . 41 Header Protection . . . . . . . . . . . . . . . . . . 40
B.1.3. S/MIME signed-only multipart/signed over a simple B.1.3. S/MIME signed-only multipart/signed over a simple
message, No Header Protection . . . . . . . . . . . . 43 message, No Header Protection . . . . . . . . . . . . 42
B.1.4. S/MIME encrypted and signed over a simple message, No B.1.4. S/MIME encrypted and signed over a simple message, No
Header Protection . . . . . . . . . . . . . . . . . . 45 Header Protection . . . . . . . . . . . . . . . . . . 44
B.1.5. No cryptographic protections over a complex B.1.5. No cryptographic protections over a complex
message . . . . . . . . . . . . . . . . . . . . . . . 48 message . . . . . . . . . . . . . . . . . . . . . . . 47
B.1.6. S/MIME signed-only signedData over a complex message, B.1.6. S/MIME signed-only signedData over a complex message,
No Header Protection . . . . . . . . . . . . . . . . 49 No Header Protection . . . . . . . . . . . . . . . . 48
B.1.7. S/MIME signed-only multipart/signed over a complex B.1.7. S/MIME signed-only multipart/signed over a complex
message, No Header Protection . . . . . . . . . . . . 52 message, No Header Protection . . . . . . . . . . . . 50
B.1.8. S/MIME encrypted and signed over a complex message, No B.1.8. S/MIME encrypted and signed over a complex message, No
Header Protection . . . . . . . . . . . . . . . . . . 55 Header Protection . . . . . . . . . . . . . . . . . . 53
B.2. Signed-only Messages . . . . . . . . . . . . . . . . . . 58 B.2. Signed-only Messages . . . . . . . . . . . . . . . . . . 57
B.2.1. S/MIME signed-only signedData over a simple message, B.2.1. S/MIME signed-only signedData over a simple message,
Wrapped Message . . . . . . . . . . . . . . . . . . . 58 Wrapped Message . . . . . . . . . . . . . . . . . . . 57
B.2.2. S/MIME signed-only multipart/signed over a simple B.2.2. S/MIME signed-only multipart/signed over a simple
message, Wrapped Message . . . . . . . . . . . . . . 60 message, Wrapped Message . . . . . . . . . . . . . . 59
B.2.3. S/MIME signed-only signedData over a simple message, B.2.3. S/MIME signed-only signedData over a simple message,
Injected Headers . . . . . . . . . . . . . . . . . . 63 Injected Headers . . . . . . . . . . . . . . . . . . 61
B.2.4. S/MIME signed-only multipart/signed over a simple B.2.4. S/MIME signed-only multipart/signed over a simple
message, Injected Headers . . . . . . . . . . . . . . 64 message, Injected Headers . . . . . . . . . . . . . . 63
B.2.5. S/MIME signed-only signedData over a complex message, B.2.5. S/MIME signed-only signedData over a complex message,
Wrapped Message . . . . . . . . . . . . . . . . . . . 67 Wrapped Message . . . . . . . . . . . . . . . . . . . 65
B.2.6. S/MIME signed-only multipart/signed over a complex B.2.6. S/MIME signed-only multipart/signed over a complex
message, Wrapped Message . . . . . . . . . . . . . . 69 message, Wrapped Message . . . . . . . . . . . . . . 67
B.2.7. S/MIME signed-only signedData over a complex message, B.2.7. S/MIME signed-only signedData over a complex message,
Injected Headers . . . . . . . . . . . . . . . . . . 72 Injected Headers . . . . . . . . . . . . . . . . . . 70
B.2.8. S/MIME signed-only multipart/signed over a complex B.2.8. S/MIME signed-only multipart/signed over a complex
message, Injected Headers . . . . . . . . . . . . . . 75 message, Injected Headers . . . . . . . . . . . . . . 73
B.3. Encrypted-and-signed Messages . . . . . . . . . . . . . . 78 B.3. Encrypted-and-signed Messages . . . . . . . . . . . . . . 76
B.3.1. S/MIME encrypted and signed over a simple message, B.3.1. S/MIME encrypted and signed over a simple message,
Wrapped Message with hcp_minimal . . . . . . . . . . 78 Wrapped Message with hcp_minimal . . . . . . . . . . 76
B.3.2. S/MIME encrypted and signed over a simple message, B.3.2. S/MIME encrypted and signed over a simple message,
Injected Headers with hcp_minimal . . . . . . . . . . 81 Injected Headers with hcp_minimal . . . . . . . . . . 79
B.3.3. S/MIME encrypted and signed over a simple message, B.3.3. S/MIME encrypted and signed over a simple message,
Injected Headers with hcp_minimal (+ Legacy Display) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Injected Headers with hcp_minimal (+ Legacy Display) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.3.4. S/MIME encrypted and signed over a simple message, B.3.4. S/MIME encrypted and signed over a simple message,
Wrapped Message with hcp_strong . . . . . . . . . . . 87 Wrapped Message with hcp_strong . . . . . . . . . . . 85
B.3.5. S/MIME encrypted and signed over a simple message, B.3.5. S/MIME encrypted and signed over a simple message,
Injected Headers with hcp_strong . . . . . . . . . . 90 Injected Headers with hcp_strong . . . . . . . . . . 88
B.3.6. S/MIME encrypted and signed over a simple message, B.3.6. S/MIME encrypted and signed over a simple message,
Injected Headers with hcp_strong (+ Legacy Display) . 93 Injected Headers with hcp_strong (+ Legacy Display) . 91
B.3.7. S/MIME encrypted and signed reply over a simple B.3.7. S/MIME encrypted and signed reply over a simple
message, Wrapped Message with hcp_minimal . . . . . . 96 message, Wrapped Message with hcp_minimal . . . . . . 94
B.3.8. S/MIME encrypted and signed reply over a simple B.3.8. S/MIME encrypted and signed reply over a simple
message, Injected Headers with hcp_minimal . . . . . 99 message, Injected Headers with hcp_minimal . . . . . 97
B.3.9. S/MIME encrypted and signed reply over a simple B.3.9. S/MIME encrypted and signed reply over a simple
message, Injected Headers with hcp_minimal (+ Legacy message, Injected Headers with hcp_minimal (+ Legacy
Display) . . . . . . . . . . . . . . . . . . . . . . 102 Display) . . . . . . . . . . . . . . . . . . . . . . 100
B.3.10. S/MIME encrypted and signed reply over a simple B.3.10. S/MIME encrypted and signed reply over a simple
message, Wrapped Message with hcp_strong . . . . . . 105 message, Wrapped Message with hcp_strong . . . . . . 103
B.3.11. S/MIME encrypted and signed reply over a simple B.3.11. S/MIME encrypted and signed reply over a simple
message, Injected Headers with hcp_strong . . . . . . 108 message, Injected Headers with hcp_strong . . . . . . 106
B.3.12. S/MIME encrypted and signed reply over a simple B.3.12. S/MIME encrypted and signed reply over a simple
message, Injected Headers with hcp_strong (+ Legacy message, Injected Headers with hcp_strong (+ Legacy
Display) . . . . . . . . . . . . . . . . . . . . . . 111 Display) . . . . . . . . . . . . . . . . . . . . . . 109
B.3.13. S/MIME encrypted and signed over a complex message, B.3.13. S/MIME encrypted and signed over a complex message,
Wrapped Message with hcp_minimal . . . . . . . . . . 114 Wrapped Message with hcp_minimal . . . . . . . . . . 113
B.3.14. S/MIME encrypted and signed over a complex message, B.3.14. S/MIME encrypted and signed over a complex message,
Injected Headers with hcp_minimal . . . . . . . . . . 118 Injected Headers with hcp_minimal . . . . . . . . . . 116
B.3.15. S/MIME encrypted and signed over a complex message, B.3.15. S/MIME encrypted and signed over a complex message,
Injected Headers with hcp_minimal (+ Legacy Display) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Injected Headers with hcp_minimal (+ Legacy Display) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.3.16. S/MIME encrypted and signed over a complex message, B.3.16. S/MIME encrypted and signed over a complex message,
Wrapped Message with hcp_strong . . . . . . . . . . . 126 Wrapped Message with hcp_strong . . . . . . . . . . . 124
B.3.17. S/MIME encrypted and signed over a complex message, B.3.17. S/MIME encrypted and signed over a complex message,
Injected Headers with hcp_strong . . . . . . . . . . 130 Injected Headers with hcp_strong . . . . . . . . . . 128
B.3.18. S/MIME encrypted and signed over a complex message, B.3.18. S/MIME encrypted and signed over a complex message,
Injected Headers with hcp_strong (+ Legacy Display) . 133 Injected Headers with hcp_strong (+ Legacy Display) . 132
B.3.19. S/MIME encrypted and signed reply over a complex B.3.19. S/MIME encrypted and signed reply over a complex
message, Wrapped Message with hcp_minimal . . . . . . 137 message, Wrapped Message with hcp_minimal . . . . . . 136
B.3.20. S/MIME encrypted and signed reply over a complex B.3.20. S/MIME encrypted and signed reply over a complex
message, Injected Headers with hcp_minimal . . . . . 141 message, Injected Headers with hcp_minimal . . . . . 140
B.3.21. S/MIME encrypted and signed reply over a complex B.3.21. S/MIME encrypted and signed reply over a complex
message, Injected Headers with hcp_minimal (+ Legacy message, Injected Headers with hcp_minimal (+ Legacy
Display) . . . . . . . . . . . . . . . . . . . . . . 145 Display) . . . . . . . . . . . . . . . . . . . . . . 144
B.3.22. S/MIME encrypted and signed reply over a complex B.3.22. S/MIME encrypted and signed reply over a complex
message, Wrapped Message with hcp_strong . . . . . . 150 message, Wrapped Message with hcp_strong . . . . . . 148
B.3.23. S/MIME encrypted and signed reply over a complex B.3.23. S/MIME encrypted and signed reply over a complex
message, Injected Headers with hcp_strong . . . . . . 153 message, Injected Headers with hcp_strong . . . . . . 152
B.3.24. S/MIME encrypted and signed reply over a complex B.3.24. S/MIME encrypted and signed reply over a complex
message, Injected Headers with hcp_strong (+ Legacy message, Injected Headers with hcp_strong (+ Legacy
Display) . . . . . . . . . . . . . . . . . . . . . . 157 Display) . . . . . . . . . . . . . . . . . . . . . . 155
Appendix C. Additional information . . . . . . . . . . . . . . . 161 Appendix C. Additional information . . . . . . . . . . . . . . . 159
C.1. Stored Variants of Messages with Bcc . . . . . . . . . . 161 C.1. Stored Variants of Messages with Bcc . . . . . . . . . . 159
Appendix D. Text Moved from Above . . . . . . . . . . . . . . . 162 Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 160
D.1. MIME Format . . . . . . . . . . . . . . . . . . . . . . . 162 D.1. Example text/plain Cryptographic Payload with Legacy
D.1.1. S/MIME Specification . . . . . . . . . . . . . . . . 163 Display Elements . . . . . . . . . . . . . . . . . . . . 160
D.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 165 D.2. Example text/html Cryptographic Payload with Legacy Display
Appendix E. Examples . . . . . . . . . . . . . . . . . . . . . . 169 Elements . . . . . . . . . . . . . . . . . . . . . . . . 161
E.1. Example text/plain Cryptographic Payload with Legacy Appendix E. Document Considerations . . . . . . . . . . . . . . 162
Display Elements . . . . . . . . . . . . . . . . . . . . 170 Appendix F. Document Changelog . . . . . . . . . . . . . . . . . 163
E.2. Example text/html Cryptographic Payload with Legacy Display Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 164
Elements . . . . . . . . . . . . . . . . . . . . . . . . 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 165
Appendix F. Document Considerations . . . . . . . . . . . . . . 171
Appendix G. Document Changelog . . . . . . . . . . . . . . . . . 172
Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174
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.
This document describes two different structures for how message This document describes two different structures for how message
headers can be cryptographically protected, and provides guidance for headers can be cryptographically protected, and provides guidance for
implementers of MUAs that generate and interpret such messages. It implementers of MUAs that generate and interpret such messages. It
takes particular care to ensure that messages interact reasonably takes particular care to ensure that messages interact reasonably
well with legacy MUAs. well with legacy MUAs.
1.1. Two Schemes of Protected Headers 1.1. Two Schemes of Header Protection
Unfortunately, there are two different schemes for cryptographically- This document addresses two different schemes for cryptographically
protected email headers that may be in use on the Internet today. protecting email header sections or fields and provides guidance to
This document addresses them both and provides guidance to
implementers. implementers.
One scheme is the form specified in S/MIME 3.1 and later, which One scheme is the form specified in S/MIME 3.1 and later, which
involves wrapping a message/rfc822 MIME object with a Cryptographic involves wrapping a message/rfc822 or message/global MIME object with
Envelope. This document calls this scheme "Wrapped Message", and it a Cryptographic Envelope around the message to protect. This
is documented in more detail in [RFC8551]. Experience has shown that document calls this scheme "Wrapped Message", and it is documented in
this form does not interact well with some legacy MUAs (see more detail in [RFC8551]. Experience has shown that this form does
Section 1.2). not interact well with some legacy MUAs (see Section 1.2).
Consequently, another form of header protection is produced and Consequently, another form of header protection is introduced, where
consumed by some MUAs, where the protected headers are placed the protected header fields are placed directly on the Cryptographic
directly on the Cryptographic Payload, without using an intervening Payload, without using an intervening message/* MIME object. This
message/* MIME object. This document calls this scheme "Injected document calls this scheme "Injected Headers", and it is documented
Headers", and it is documented in more detail in Section 4.1.2.4 and in more detail in this document, in Section 2.3.3 and Section 2.5.3.
Section 4.1.4.4.
1.2. Problems with Wrapped Messages 1.2. Problems with Wrapped Messages
Several legacy MUAs have revealed rendering issues when dealing with Several legacy MUAs have revealed rendering issues when dealing with
a message with headers protected by the Wrapped Message scheme. In a message that uses the Wrapped Message header protection scheme.
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
issues:
* Broken or incomplete implementations In the worst cases, some mail user agents cannot render message/
rfc822 message subparts at all, in violation of baseline MIME
requirements as described on page 5 of [RFC2049]. This leaves all
wrapped messages unreadable by any recipient using such a MUA.
* Lack of a simple means to distinguish "forwarded message" and In other cases, the user sees an attachment suggesting a forwarded
"wrapped message" (for the sake of Header Protection) email message, which -- in fact -- contains the protected email
message that should be rendered directly. In most of these cases,
the user can click on the attachment to view the protected message.
* Not enough guidance with respect to handling of Header Fields on However, viewing the protected message as an attachment in isolation
both the sending and the receiving side may strip it of any security indications, leaving the user unable to
assess the cryptographic properties of the message. Worse, for
encrypted messages, interacting with the protected message in
isolation may leak contents of the cleartext, for example, if the
reply is not also encrypted.
1.3. Problems with Injected Headers 1.3. Problems with Injected Headers
A legacy MUA dealing with an encrypted message that has some header A legacy MUA dealing with an encrypted message that has some header
fields obscured using the Injected Headers scheme will not render the fields obscured using the Injected Headers scheme will not render the
obscured header fields to the user at all. A workaround "legacy obscured header fields to the user at all. A workaround "legacy
display" mechanism is provided in this document, which most legacy display" mechanism is provided in this document, which most legacy
MUAs should render to the user, albeit not in the same location that MUAs should render to the user, albeit not in the same location that
the header fields would normally be rendered. the header fields would normally be rendered.
1.4. Motivation 1.4. Motivation
Furthermore, the need (technical) Data Minimization, which includes Users generally do not understand the distinction between message
data sparseness and hiding all technically concealable information, body and message header. When an e-mail message has cryptographic
has grown in importance over the past several years. In addition, protections that cover the message body, but not the header fields,
backwards compatibility must be considered when it is possible to do several attacks become possible.
so without compromising privacy and security.
No mechanism for Header Protection has been standardized for PGP/MIME
(Pretty Good Privacy) [RFC3156] yet. PGP/MIME developers have
implemented ad-hoc header-protection, and would like to see a
specification that is applicable to both S/MIME and PGP/MIME.
This document describes the problem statement (Section 2), generic
use cases (Section 3) and the specification for Header Protection
(Section 4) with guidance on MIME format, sender and receiver
processing .
[I-D.ietf-lamps-header-protection-requirements] defines the For example, a legacy signed message has a signature that covers the
requirements that this specification is based on. body but not the header fields. An attacker can therefore modify the
header fields (including the Subject header) without invalidating the
signature. Since most readers consider a message body in the context
of the message's Subject header, the meaning of the message itself
could change drastically (under the attacker's control) while still
retaining the same cryptographic indicator of authenticity.
This document is in an early draft state and contains a proposal on In another example, a legacy encrypted message has its body
which to base future discussions of this topic. In any case, the effectively hidden from an adversary that snoops on the message. But
final mechanism is to be determined by the IETF LAMPS WG. if the header fields are not also encrypted, significant information
about the message (such as the message Subject) will leak to the
inspecting adversary.
1.5. Other Protocols to Protect Email Headers However, if the sending and receiving MUAs ensure that cryptographic
protections cover the message headers as well as the message body,
these attacks are defeated.
A range of protocols for the protection of electronic mail (email) 1.4.1. Backward Compatibility
exists, which allows one to assess the authenticity and integrity of
the email headers section or selected Header Fields from the domain-
level perspective, specifically DomainKeys Identified Mail (DKIM)
[RFC6376], as used by Domain-based Message Authentication, Reporting,
and Conformance (DMARC) [RFC7489]. These protocols provide a domain-
based reputation mechanism that can be used to mitigate some forms of
unsolicited email (spam). At the same time, these protocols can
provide a level of cryptographic integrity and authenticity for some
headers, depending on how they are used. However, integrity
protection and proof of authenticity are both tied to the domain name
of the sending e-mail address, not the sending address itself, so
these protocols do not provide end-to-end protection, and are
incapable of providing any form of confidentiality.
1.6. Requirements Language If the sending MUA is unwilling to generate such a fully-protected
message due to the potential for rendering, usability,
deliverability, or security issues, these defenses cannot be
realized.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The sender cannot know what MUA (or MUAs) the recipient will use to
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this handle the message. Thus, an outbound message format that is
document are to be interpreted as described in [RFC2119]. backward-compatible with as many legacy implementations as possible
is a more effective vehicle for providing the whole-message
cryptographic protections described above.
1.7. Terms This document aims for backward compatibility with legacy clients to
the extent possible. In some cases, like when a user-visible header
like the Subject is cryptographically hidden, the message cannot
behave entirely identically to a legacy client. But accommodations
are described here that ensure a rough semantic equivalence for
legacy clients even in these cases.
The following terms are defined for the scope of this document: 1.4.2. Deliverability
* Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A A message that cannot be delivered is less useful than a message with
form of active wiretapping attack in which the attacker intercepts perfect cryptographic protections. Senders want their messages to
and selectively modifies communicated data to masquerade as one or reach the intended recipients.
more of the entities involved in a communication association."
Note: Historically, MITM has stood for '_Man_-in-the-middle'. Given the current state of the Internet mail ecosystem, encrypted
However, to indicate that the entity in the middle is not always a messages in particular cannot shield all of their header fields from
human attacker, MITM can also stand for 'Machine-in-the-middle' or visibility and still be guaranteed delivery to their intended
'Meddler-in-the-middle'. recipient.
* S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. This document accounts for this concern by providing a mechanism
[RFC8551]) (Section 2.3.2) that prioritizes initial deliverability (at the cost
of some header leakage) while facilitating future message variants
that shield more header metadata from casual inspection.
* PGP/MIME: MIME Security with OpenPGP (cf. [RFC3156]) 1.5. Other Protocols to Protect Email Header Fields
* Message: An Email Message consisting of Header Fields A separate pair of protocols also provides some cryptographic
(collectively called "the Header Section of the message") protection for the email message header integrity: DomainKeys
followed, optionally, by a Body; cf. [RFC5322]. Identified Mail (DKIM) [RFC6376], as used in combination with Domain-
based Message Authentication, Reporting, and Conformance (DMARC)
[RFC7489]. This pair of protocols provides a domain-based reputation
mechanism that can be used to mitigate some forms of unsolicited
email (spam).
Note: To avoid ambiguity, this document does not use the terms However, the DKIM+DMARC suite provides cryptographic protection at a
"Header" or "Headers" in isolation, but instead always uses different scope than the mechanisms described here. In particular,
"Header Field" to refer to the individual field and "Header the message integrity and authentication signals provided by
Section" to refer to the entire collection; cf. [RFC5322]. DKIM+DMARC correspond to the domain name of the sending e-mail
address, not the sending address itself, so DKIM+DMARC not provide
end-to-end protection. DKIM+DMARC are typically applied to messages
by (and interpreted by) mail transfer agents, not mail user agents.
The mechanisms in this document are typically applied to messages by
(and interpreted by) mail user agents.
* Header Field (HF): cf. [RFC5322] Header Fields are lines beginning Furthermore, DKIM+DMARC only provides cryptographic integrity and
with a field name, followed by a colon (":"), followed by a field authentication, not encryption. So cryptographic confidentiality is
body (value), and terminated by CRLF. not available from that suite.
* Header Section (HS): The Header Section is a sequence of lines of DKIM+DMARC can be used on any message, including messages formed as
characters with special syntax as defined in [RFC5322]. It is the described in this document. There should be no conflict between
(top) section of a Message containing the Header Fields. these schemes.
* Body: The Body is simply a sequence of bytes that follows the 1.6. Applicability to PGP/MIME
Header Section and is separated from the Header Section by an
empty line (i.e., a line with nothing preceding the CRLF); cf
[RFC5322]. It is the (bottom) section of Message containing the
payload of a Message. Typically, the Body consists of a (possibly
multipart) MIME [RFC2045] construct.
* MIME Header Fields: Header Fields describing content of a MIME This document describes end-to-end cryptographic protections for
entity [RFC2045], in particular the MIME structure. Each MIME e-mail messages in reference to S/MIME ([RFC8551]).
Header Field name starts with "Content-" prefix.
* MIME Header Section (part): The collection of MIME Header Fields. Comparable end-to-end cryptographic protections can also be provided
"MIME Header Section" refers to a Header Sections that contains by PGP/MIME ([RFC3156]).
only MIME Header Fields, whereas "MIME Header Section part" refers
to the MIME Header Fields of a Header Section that - in addition
to MIME Header Fields - also contains non-MIME Header Fields.
* Essential Header Fields (EHF): The minimum set of Header Fields an The mechanisms in this document should be applicable in the PGP/MIME
Outer Message Header Section SHOULD contain; cf. Appendix D.1.2.5. protections as well as S/MIME protections, but analysis and
implementation in this document focuses on S/MIME.
* Header Protection (HP): cryptographic protection of email Header To the extent that any divergence from the mechanism described here
Sections (or parts of it) for signatures and/or encryption is necessary for PGP/MIME, that divergence is out of scope for this
document.
* Protection Levels (PL): The level of protection applied to a 1.7. Requirements Language
Message, e.g. 'signature and encryption' or 'signature only' (cf.
Section 3.2).
* Protected: Portions of a message that have had any Protection The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Levels applied. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
* Protected Message: A Message that has had any Protection Levels 1.8. Terms
applied.
* Unprotected: Portions of a Message that has had no Protection The following terms are defined for the scope of this document:
Levels applied.
* Unprotected Message: A Message that has had no Protection Levels * S/MIME: Secure/Multipurpose Internet Mail Extensions (see
applied. [RFC8551])
* Submission Entity: The entity which executes further processing of * PGP/MIME: MIME Security with OpenPGP (see [RFC3156])
the Message (incl. transport towards the receiver), after
protection measures have been applied to the Message.
Note: The Submission Entity varies among implementations, mainly * Message: An Email Message consisting of Header Fields
depending on the stage where protection measures are applied: E.g. (collectively called "the Header Section of the message")
a Message Submission Agent (MSA) [RFC6409] or another followed, optionally, by a Body; see [RFC5322].
(proprietary) solution. The latter is particularly relevant, if
protection is implemented as a plugin solution. Some
implementations may determine the destination recipients by
reading the To, Cc and Bcc Header Fields of the Outer Message.
* Original Message (OrigM): The Message to be protected before any Note: To avoid ambiguity, this document avoids using the terms
protection-related processing has been applied on the sending "Header" or "Headers" in isolation, but instead always uses
side. If the source is not a "message/rfc822" Message, OrigM is "Header Field" to refer to the individual field and "Header
defined as the "virtual" Message that would be constructed for Section" to refer to the entire collection.
sending it as unprotected email.
* Inner Message (InnerM): The Message to be protected which has had * Header Field: A Header Field is a line beginning with a field
wrapping and protection measures applied on the sending side OR name, followed by a colon (":"), followed by a field body (value),
the resulting Message once decryption and unwrapping on the and terminated by CRLF; see [RFC5322].
receiving side has been performed. Typically, the Inner Message
is in clear text. The Inner Message is a subset of (or the same
as) the Original Message. The Inner Message must be the same on
the sending and the receiving side.
* Outer Message (OuterM): The Message as provided to the Submission * Header Section: The Header Section is a sequence of lines of
Entity or received from the last hop respectively. The Outer characters with special syntax as defined in [RFC5322]. It is the
Message normally differs on the sending and the receiving side top section of a Message, and it contains the Header Fields
(e.g. new Header Fields are added by intermediary nodes). associated with the Message itself.
* Receiving User Facing Message (RUFM): The Message used for * Body: The Body is the part of a Message that follows the Header
rendering at the receiving side. Typically this is the same as Section and is separated from the Header Section by an empty line
the Inner Message. (i.e., a line with nothing preceding the CRLF); see [RFC5322]. It
is the (bottom) section of Message containing the payload of a
Message. Typically, the Body consists of a (possibly multipart)
MIME [RFC2045] construct.
* Data Minimization: Data sparseness and hiding of all technically * Header Protection: cryptographic protection of email Header
concealable information whenever possible. Sections (or parts of it) for signatures and/or encryption
* Cryptographic Layer, Cryptographic Payload, Cryptographic * Cryptographic Layer, Cryptographic Payload, Cryptographic
Envelope, Structural Headers, Main Body Part, User-Facing Headers, Envelope, Structural Headers, Main Body Part, User-Facing Headers,
and MUA are all used as defined in and MUA are all used as defined in
[I-D.ietf-lamps-e2e-mail-guidance] [I-D.ietf-lamps-e2e-mail-guidance]
* Legacy MUA: a MUA that does not understand protected headers as * Legacy MUA: a MUA that does not understand header protection as
described in this document. A Legacy Non-Crypto MUA is incapable described in this document. A Legacy Non-Crypto MUA is incapable
of doing any end-to-end cryptographic operations. A Legacy Crypto of doing any end-to-end cryptographic operations. A Legacy Crypto
MUA is capable of doing cryptographic operations, but does not MUA is capable of doing cryptographic operations, but does not
understand or generate protected headers. understand or generate messages with header protection.
* Wrapped Message: The protected headers scheme that uses the * Wrapped Message: The header protection scheme that uses the
mechanism described in [RFC8551], where the Cryptographic Payload mechanism described in [RFC8551], where the Cryptographic Payload
is a message/rfc822 or message/global MIME object. is a message/rfc822 or message/global MIME object. (see
Section 2.2).
* Injected Headers: The protected headers scheme that uses the
mechanism described in this document (see Section 4.1.2.4 and
Section 4.1.4.4), where the protected headers are inserted on the
Cryptographic Payload directly.
* Header Confidentiality Policy: documented in Section 4.1.2.2
2. Problem Statement
The LAMPS charter contains the following Work Item:
Update the specification for the cryptographic protection of email
headers -- both for signatures and encryption -- to improve the
implementation situation with respect to privacy, security,
usability and interoperability in cryptographically-protected
electronic mail. Most current implementations of
cryptographically-protected electronic mail protect only the body
of the message, which leaves significant room for attacks against
otherwise-protected messages.
In the following a set of challenges to be addressed:
[[ TODO: Enhance this section, add more items to the following. ]]
2.1. Privacy
* (Technical) Data Minimization, which includes data sparseness and
hiding all technically concealable information whenever possible
2.2. Security
* Prevent MITM attacks (cf. [RFC4949])
2.3. Usability
* Improved User interaction / User experience, in particular at the
receiving side
2.4. Interoperability
* Interoperability with [RFC8551] implementations
3. Use Cases
In the following, the reader can find a list of the generic use cases
that need to be addressed for Messages with Header Protection (HP).
These use cases apply regardless of technology (S/MIME, PGP/MIME,
etc.) used to achieve HP.
3.1. Interactions
The following use cases assume that at least the sending side
supports Header Protection as specified in this document. Receiving
sides that support this specification are expected to be able to
distinguish between Messages that use Header Protection as specified
in this document, and (legacy) Mail User Agents (MUAs) which do not
implement this specification.
[[ TODO: Verify once solution is stable and update last sentence. ]]
3.1.1. Main Use Case
Both the sending and receiving side (fully) support Header Protection
as specified in this document.
The main use case is specified in Section 4.1.
3.1.2. Backward Compatibility Use Cases
Regarding backward compatibility, the main distinction is based on
whether or not the receiving side conforms to MIME according to
[RFC2046], ff., which in particular also includes Section 2 of
[RFC2049] on "MIME Conformance". The following excerpt is
contextually relevant:
A mail user agent that is MIME-conformant MUST:
[...]
-- Recognize and display at least the RFC822 message
encapsulation (message/rfc822) in such a way as to
preserve any recursive structure, that is, displaying
or offering to display the encapsulated data in
accordance with its media type.
-- Treat any unrecognized subtypes as if they were
"application/octet-stream".
[...]
An MUA that meets the above conditions is said to be MIME-
conformant. A MIME-conformant MUA is assumed to be "safe" to
send virtually any kind of properly-marked data to users of
such mail systems, because these systems are, at a minimum,
capable of treating the data as undifferentiated binary, and
will not simply splash it onto the screen of unsuspecting
users.
[[ TODO: The compatibility of legacy HP systems with this new
solution, and how to handle issues surrounding future maintenance for
these legacy systems, will be decided by the LAMPS WG. ]]
3.1.2.1. Receiving Side MIME-Conformant
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. However, the receiving side is MIME-conformant
according to [RFC2045], ff. (cf. Section 3.1.2).
This use case is specified in Section 4.2.1.
Note: This case should perform as expected if the sending side
applies this specification as outlined in Section 4.1.
[[ TODO: Verify once solution is stable and update last sentence. ]]
3.1.2.2. Receiving Side Not MIME-Conformant
The sending side (fully) supports Header Protection as specified in
this document, while the receiving side does not support this
specification. Furthermore, the receiving side is *not* MIME-
conformant according to [RFC2045], ff. (cf. Section 3.1.2).
This use case is specified in Section 4.2.2.
3.2. Protection Levels
3.2.1. In-Scope
The following Protection Levels are in scope for this document:
a) Signature and encryption
Messages containing a cryptographic signature, which are also
encrypted.
b) Signature only
Messages containing a cryptographic signature, but which are not
encrypted.
3.2.2. Out-of-Scope
Legacy implementations, implementations not (fully) compliant with
this document or corner-cases may lead to further Protection Levels
to appear on the receiving side, such as (list not exhaustive):
* Triple wrap
* Encryption only
* Encryption before signature
* Signature and encryption, but:
- Signature fails to validate
- Signature validates but the signing certificate revoked
* Signature only, but:
- with multiple valid signatures, layered atop each other
These Protection Levels, as well as any further Protection Levels not
listed in Section 3.2.1 are beyond the scope of this document.
4. Specification
This section contains the specification for Header Protection in S/
MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0).
Note: It is likely that PGP/MIME [RFC3156] will also incorporate this
specification or parts of it.
This specification applies to the Protection Levels "signature &
encryption" and "signature only" (cf. Section 3.2):
Sending and receiving sides MUST implement the "signature and
encryption" Protection Level, which SHOULD be used as default on the
sending side.
Certain implementations may decide to send "signature only" Messages,
depending on the circumstances and customer requirements. Sending
sides MAY and receiving sides MUST implement "signature only"
Protection Level.
It generally is NOT RECOMMENDED to send a Message with any other
Protection Level. On the other hand, the receiving side must be
prepared to receive Messages with other Protection Levels.
[[ TODO: Further study is necessary to determine whether - and if yes
to what extent - additional guidance for handling messages with other
Protection Levels, e.g. "encryption only" at the receiving side
should be included in this document. ]]
4.1. Main Use Case * Injected Headers: The header protection scheme that uses the
mechanism described in this document (see Section 2.1), where the
protected header fields are inserted on the Cryptographic Payload
directly.
This section applies to the main use case, where the sending and * Header Confidentiality Policy: a functional specification of which
receiving side (fully) support Header Protection as specified herein header fields should be obscured when composing an encrypted
(cf. Section 3.1.1). message with header protection. See Section 2.3.2.
Note: The sending side specification of the main use case is also 1.9. Document Scope
applicable to the cases where the sending side (fully) supports
Header Protection as specified herein, while the receiving side does
not, but is MIME-conformant according to [RFC2045], ff. (cf.
Section 3.1.2 and Section 3.1.2.1).
Further backward compatibility cases are defined in Section 4.2. This document describes sensible, simple behavior for a program that
generates an e-mail message with standard end-to-end cryptographic
protections, following the guidance in
[I-D.ietf-lamps-e2e-mail-guidance]. An implementation conformant to
this draft will produce messages that have cryptographic protection
that covers the message's headers as well as its body.
4.1.1. MIME Format This document also describes sensible, simple behavior for a program
that interprets such a message, in a way that can take advantage of
these protections covering the header fields as well as the body.
4.1.1.1. Introduction The message generation guidance aims to minimize negative
interactions with any legacy receiving client while providing
actionable cryptographic properties for modern receiving clients.
As per S/MIME version 3.1 and later (cf. [RFC8551]), the sending In particular, this document focuses on two standard types of
client MAY wrap a full MIME message in a message/RFC822 wrapper in cryptographic protection that cover the entire message:
order to apply S/MIME security services to these header fields.
To help the receiving side to distinguish between a forwarded and a * A cleartext message with a single signature, and
wrapped message, the Content-Type header field parameter "forwarded"
is added as defined in [I-D.melnikov-iana-reg-forwarded].
The simplified (cryptographic overhead not shown) MIME structure of * An encrypted message that contains a single cryptographic
such an Email Message looks as follows: signature.
<Outer Message Header Section (unprotected)> 1.9.1. Out of Scope
<Outer Message Body (protected)> While the generation guidance aims to provide minimal disruption for
any legacy client, such a client by definition does not implement
this document.
<MIME Header Section (wrapper)> Therefore, the document does not attempt to provide guidance for
legacy clients.
<Inner Message Header Section> Furthermore, this document does not explicitly contemplate unusual
(and tricky) variants of cryptographic message protections, including
any of these:
<Inner Message Body> * Encrypted-only message (without a cryptographic signature)
The following example demonstrates how an Original Message might be * Triple-wrapped message
protected, i.e., the Original Message is contained as Inner Message
in the Protected Body of an Outer Message. It illustrates the first
Body part (of the Outer Message) as a "multipart/signed"
(application/pkcs7-signature) media type:
Lines are prepended as follows: * Signed message with multiple signatures
* "O: " Outer Message Header Section * Encrypted message with a cryptographic signature outside the
encryption.
* "I: " Message Header Section All such messages are out of scope.
* "W: " Wrapper (MIME Header Section) 2. Specification
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: To: somebody@example.net
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=boundary-AM
This is a multipart message in MIME format. As mentioned in Section 1.1, this document describes two ways to
--boundary-AM provide end-to-end cryptographic protection for an e-mail message
W: Content-Type: message/RFC822; forwarded=no that includes all header fields known to the sender at message
W: composition time.
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified. A receiving MUA MUST be able to handle both header protection
schemes, as described in Section 2.5.
--boundary-AM A sending MUA MUST be able to generate the Injected Headers scheme
Content-Transfer-Encoding: base64 (Section 2.3.3), and MAY generate the Wrapped Message scheme
Content-Type: application/pkcs7-signature (Section 2.3.4).
[[base-64 encoded signature]] 2.1. Injected Headers Scheme
--boundary-AM-- The Injected Headers scheme places all header fields to be protected
directly into the header section of the Cryptographic Payload.
The Outer Message Header Section is unprotected, while the remainder For an encrypted message that has at least one user-visible header
(Outer Message Body) is protected. The Outer Message Body consists field omitted or obscured outside of the Cryptographic Payload, those
of the wrapper (MIME Header Section) and the Inner Message (Header header fields MAY also be duplicated into decorative copies in the
Section and Body). Main Body MIME part of the Cryptograhic Payload itself. These
decorative copies within the message are known as "legacy display
elements".
The wrapper is a simple MIME Header Section with media type "message/ Composing a message with the Injected Headers scheme is described in
rfc822" containing a Content-Type header field parameter Section 2.3.3. Rendering such a message is described in
"forwarded=no" followed by an empty line. Section 2.5.3.
If the source is an Original (message/rfc822) Message, the Inner 2.2. Wrapped Message Scheme
Message Header Section is typically the same as (or a subset of) the
Original Message Header Section, and the Inner Message Body is
typically the same as the Original Message Body.
The Inner Message itself may contain any MIME structure. The Wrapped Message scheme creates a message/rfc822 (or message/
global) MIME object containing the message and all header fields to
be protected, and then uses that encapsulated MIME part as the
Cryptographic Payload.
Note: It is still to be decided by the LAMPS WG whether or not to Composing a message with the Wrapped Message scheme is described in
recommend an alternative MIME format as described in Appendix D.1.1.1 Section 2.3.4. Rendering such a message is described in
(instead of the currently standardized and above defined format). Section 2.5.4.
4.1.2. Sending Side 2.3. Sending Side
This section describes the process an MUA should use to apply This section describes the process an MUA should use to apply
cryptographic protection to an e-mail message with header protection. cryptographic protection to an e-mail message with header protection.
We start by describing the legacy message composition process as a We start by describing the legacy message composition process as a
baseline. baseline.
4.1.2.1. Composing a Cryptographically-Protected Message Without Header 2.3.1. Composing a Cryptographically-Protected Message Without Header
Protection Protection
[I-D.ietf-lamps-e2e-mail-guidance] describes the typical process for [I-D.ietf-lamps-e2e-mail-guidance] describes the typical process for
a legacy crypto MUA to apply cryptographic protections to an e-mail a legacy crypto MUA to apply cryptographic protections to an e-mail
message. That guidance and terminology is replicated here for message. That guidance and terminology is replicated here for
reference: reference:
* origbody: the traditional unprotected message body as a well- * origbody: the traditional unprotected message body as a well-
formed MIME tree (possibly just a single MIME leaf part). As a formed MIME tree (possibly just a single MIME leaf part). As a
well-formed MIME tree, origbody already has structural headers well-formed MIME tree, origbody already has structural headers
(Content-*) present. (Content-*) present.
skipping to change at page 18, line 9 skipping to change at page 13, line 36
the mail system: the mail system:
* Apply crypto to origbody, yielding MIME tree output * Apply crypto to origbody, yielding MIME tree output
* For each header name and value (h,v) in origheaders: * For each header name and value (h,v) in origheaders:
- Add header h of output with value v - Add header h of output with value v
* Return output * Return output
4.1.2.2. Header Confidentiality Policy 2.3.2. Header Confidentiality Policy
When composing an encrypted message with protected headers, the When composing an encrypted message with header protection, the
composing MUA needs a Header Confidentialiy Policy. In this composing MUA needs a Header Confidentiality Policy (HCP). In this
document, we represent that Header Confidentiality Policy as a document, we represent that Header Confidentiality Policy as a
function hcp: function hcp:
* hcp(name, val_in) --> val_out: this function takes a header field * hcp(name, val_in) --> val_out: this function takes a header field
name name and initial value val_in as arguments, and returns a name name and initial value val_in as arguments, and returns a
replacement header value val_out. If val_out is the special value replacement header value val_out. If val_out is the special value
null, it mean that the header in question should be omitted from null, it mean that the header field in question should be omitted
the set of headers visible outside the Cryptographic Envelope. from the set of header fields visible outside the Cryptographic
Envelope.
For example, an MUA that only obscures the Subject header field by For example, an MUA that only obscures the Subject header field by
replacing it with the literal string [...] and does not offer replacing it with the literal string [...] and does not offer
confidentiality to any other header fields would be represented as confidentiality to any other header fields would be represented as
(in pseudocode): (in pseudocode):
hcp(name, val_in) → val_out: hcp(name, val_in) → val_out:
if name is 'Subject': if name is 'Subject':
return '[...]' return '[...]'
else: else:
return val_in return val_in
Note that such a policy is only needed when the end-to-end Note that such a policy is only needed when the end-to-end
protections include encryption (confidentiality). No comparable protections include encryption (confidentiality). No comparable
policy is needed for other end-to-end cryptographic protections policy is needed for other end-to-end cryptographic protections
(integrity and authenticity), as they are simply uniformly applied so (integrity and authenticity), as they are simply uniformly applied so
that all header fields known by the sender have these protections. that all header fields known by the sender have these protections.
This asymmetry is an unfortunate consequence of complexities in This asymmetry is an unfortunate consequence of complexities in
message delivery systems, some of which may reject, drop, or delay message delivery systems, some of which may reject, drop, or delay
messages where all headers are removed from the top-level MIME messages where all header fields are removed from the top-level MIME
object. object.
This document does not mandate any particular Header Confidentiality This document does not mandate any particular Header Confidentiality
Policy, though it offers guidance for MUA implementers in selecting Policy, though it offers guidance for MUA implementers in selecting
one in Section 4.1.3. Future documents may recommend or mandate such one in Section 2.4. Future documents may recommend or mandate such a
a policy for an MUA with specific needs. Such a recommendation might policy for an MUA with specific needs. Such a recommendation might
be motivated by descriptions of metadata-derived attacks, or stem be motivated by descriptions of metadata-derived attacks, or stem
from research about message deliverability, or describe new from research about message deliverability, or describe new
signalling mechanisms, but these topics are out of scope for this signalling mechanisms, but these topics are out of scope for this
document. document.
4.1.2.3. Composing with "Wrapped Message" Header Protection 2.3.3. Composing with "Injected Headers" Header Protection
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:
* For header name and value (h,v) in origheaders:
- Add header h of origbody with value v
* 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]):
- Let payload be a new MIME part with one header: Content-Type:
message/global; forwarded=no, and whose body is origbody.
* Else:
- Let payload be a new MIME part with one header: Content-Type:
message/rfc822; forwarded=no, and whose body is origbody.
* Apply crypto to payload, yielding MIME tree output
* If crypto contains encryption:
- Create new empty list of header field names and values newh
- For header name and value (h,v) in origheaders:
o Let newval be hcp(h, v)
o If newval is not null:
+ Append (h,newval) to newh
- Set origheaders to newh
* For header name and value (h,v) in origheaders:
- Add header h of output with value v
* Return output
Note that the Header Confidentiality Policy hcp is ignored if crypto
does not contain encryption. This is by design.
4.1.2.4. Composing with "Injected Headers" Header Protection The "Injected Headers" header protection scheme places the header
fields to be protected directly on the cryptographic payload. Unlike
in the "Wrapped Scheme" (see compose-wrapped-message), there is no
wrapping of the message body in any additional message/* MIME part.
This section describes how to generate such a message.
To compose a message using "Injected Headers" header protection, the To compose a message using "Injected Headers" header protection, the
composing MUA needs one additional input in addition to the Header composing MUA needs one additional input in addition to the Header
Confidentiality Policy hcp defined in Section 4.1.2.2. Confidentiality Policy hcp defined in Section 2.3.2.
* legacy: a boolean value, indicating whether any recipient of the * legacy: a boolean value, indicating whether any recipient of the
message is believed to have a legacy client. If all recipients message is believed to have a legacy client. If all recipients
are known to implement this draft, legacy should be set to false. 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 (How a MUA determines the value of legacy is out of scope for this
document; an initial implementation can simply set it to true) document; an initial implementation can simply set it to true)
Enabling visibility of obscured headers for decryption-capable legacy Enabling visibility of obscured header fields for decryption-capable
clients requires transforming a header list into a readable form and legacy clients requires transforming a header list into a readable
including it as a "Legacy Display" element in specially-marked parts form and including it as a decorative "Legacy Display" element in
of the message. This document recommends two different mechanisms: specially-marked parts of the message. This document recommends two
one for a text/html Main Body part of the e-mail message, and one for different mechanisms for such a decorative adjustment: one for a
a text/plain Main Body part. This document does not recommend adding text/html Main Body part of the e-mail message, and one for a text/
a Legacy Display element to any other part. plain Main Body part. This document does not recommend adding a
Legacy Display element to any other part.
Please see [I-D.ietf-lamps-e2e-mail-guidance] for guidance on Please see [I-D.ietf-lamps-e2e-mail-guidance] for guidance on
identifying the parts of a message that are a Main Body Part. identifying the parts of a message that are a Main Body Part.
The revised algorithm for applying cryptographic protection to a The revised algorithm for applying cryptographic protection to a
message is as follows: message is as follows:
* if crypto contains encryption, and legacy is true: * if crypto contains encryption, and legacy is true:
- Create ldlist, an empty list of (header, value) pairs - Create ldlist, an empty list of (header, value) pairs
- For each header name and value (h,v) in origheaders: - For each header field name and value (h,v) in origheaders:
o If h is user-facing (see o If h is user-facing (see
[I-D.ietf-lamps-e2e-mail-guidance]): [I-D.ietf-lamps-e2e-mail-guidance]):
+ If hcp(h,v) is not v: + If hcp(h,v) is not v:
* Append (h,v) to ldlist * Append (h,v) to ldlist
- If ldlist is not empty: - If ldlist is not empty:
o Identify each leaf MIME part of payload that represents the o Identify each leaf MIME part of payload that represents the
"main body" of the message. "main body" of the message.
o For each "Main Body Part" bodypart of type text/plain or o For each "Main Body Part" bodypart of type text/plain or
text/html: text/html:
+ Insert Legacy Display element header list ldlist into the + Insert Legacy Display element header list ldlist into the
content of bodypart (see Section 4.1.2.4.1 for text/plain content of bodypart (see Section 2.3.3.1 for text/plain
and Section 4.1.2.4.2 for text/html) and Section 2.3.3.2 for text/html)
+ Add Content-Type parameter hp-legacy-display with value 1 + Add Content-Type parameter hp-legacy-display with value 1
to bodypart to bodypart
* For each header name and value (h,v) in origheaders: * For each header field name and value (h,v) in origheaders:
- Add header h of MIME part payload with value v - Add header field h of MIME part payload with value v
* Set the protected-headers parameter on the Content-Type of payload * Set the protected-headers parameter on the Content-Type of payload
to v1 to v1
* Apply crypto to payload, producing MIME tree output * Apply crypto to payload, producing MIME tree output
* If crypto contains encryption: * If crypto contains encryption:
- Create new empty list of header field names and values newh - Create new empty list of header field names and values newh
- For header name and value (h,v) in origheaders: - For header field name and value (h,v) in origheaders:
o Let newval be hcp(h, v) o Let newval be hcp(h,v)
o If newval is not null: o If newval is not null:
+ Add newh[h] to newval + Add newh[h] to newval
- Set origheaders to newh - Set origheaders to newh
* For each header name and value (h,v) in origheaders: * For each header field name and value (h,v) in origheaders:
- Add header h of output with value v - Add header field h of output with value v
* Return output * Return output
Note that both new parameters (hcp and legacy) are effectively Note that both new parameters (hcp and legacy) are effectively
ignored if crypto does not contain encryption. This is by design, ignored if crypto does not contain encryption. This is by design,
because they are irrelevant for signed-only cryptographic because they are irrelevant for signed-only cryptographic
protections. protections.
4.1.2.4.1. Adding a Legacy Display Element to a text/plain Part 2.3.3.1. Adding a Legacy Display Element to a text/plain Part
For a list of obscured headers represented as (header, value) pairs, For a list of obscured header fields represented as (header, value)
concatenate them as a set of lines, with one newline at the end of pairs, concatenate them as a set of lines, with one newline at the
each pair. Add an additional trailing newline after the resultant end of each pair. Add an additional trailing newline after the
text, and prepend the entire list to the body of the text/plain part. resultant text, and prepend the entire list to the body of the text/
plain part.
For example, if the list of obscured headers was [("Cc", For example, if the list of obscured header fields was [("Cc",
"alice@example.net"), ("Subject", "Thursday's meeting")], then a "alice@example.net"), ("Subject", "Thursday's meeting")], then a
text/plain part that originally contained: text/plain part that originally contained:
I think we should skip the meeting. I think we should skip the meeting.
Would become: Would become:
Subject: Thursday's meeting Subject: Thursday's meeting
Cc: alice@example.net Cc: alice@example.net
I think we should skip the meeting. I think we should skip the meeting.
4.1.2.4.2. Adding a Legacy Display Element to a text/html Part 2.3.3.2. Adding a Legacy Display Element to a text/html Part
Adding a Legacy Display Element to a text/html part is similar to how Adding a Legacy Display Element to a text/html part is similar to how
it is added to a text/plain part (see Section 4.1.2.4.1). Instead of it is added to a text/plain part (see Section 2.3.3.1). Instead of
adding the obscured headers to a block of text delimited by a blank adding the obscured header fields to a block of text delimited by a
line, the composing MUA injects them in an HTML <div> element blank line, the composing MUA injects them in an HTML <div> element
annotated with a class attribute of header-protecton-legacy-display. annotated with a class attribute of header-protection-legacy-display.
The content and formatting of this decorative <div> have no strict The content and formatting of this decorative <div> have no strict
requirements, but they SHOULD represent all the obscured headers in a requirements, but they SHOULD represent all the obscured header
readable fashion. A simple approach is to assemble the text in the fields in a readable fashion. A simple approach is to assemble the
same way as Section 4.1.2.4.1, wrap it in a verbatim <pre> element, text in the same way as Section 2.3.3.1, wrap it in a verbatim <pre>
and put that element in the annotated <div>. element, and put that element in the annotated <div>.
The annotated <div> should be placed as close to the start of the The annotated <div> should be placed as close to the start of the
<body> as possible, where it will be visible when viewed with a <body> as possible, where it will be visible when viewed with a
standard HTML renderer. standard HTML renderer.
For example, if the list of obscured headers was [("Cc", For example, if the list of obscured header fields was [("Cc",
"alice@example.net"), ("Subject", "Thursday's meeting")], then a "alice@example.net"), ("Subject", "Thursday's meeting")], then a
text/html part that originally contained: text/html part that originally contained:
<html><head><title></title></head><body> <html><head><title></title></head><body>
<p>I think we should skip the meeting.</p> <p>I think we should skip the meeting.</p>
</body></html> </body></html>
Would become: Would become:
<html><head><title></title></head><body> <html><head><title></title></head><body>
<div class="header-protection-legacy-display"> <div class="header-protection-legacy-display">
<pre>Subject: Thursday's meeting <pre>Subject: Thursday's meeting
Cc: alice@example.net</pre></div> Cc: alice@example.net</pre></div>
<p>I think we should skip the meeting.</p> <p>I think we should skip the meeting.</p>
</body></html> </body></html>
4.1.2.4.3. Do Not Add a Legacy Display Element to Other Content-Types 2.3.3.3. Only Add a Legacy Display Element to Main Body Parts
Some messages may contain a text/plain or text/html subpart that is
_not_ a main body part. For example, an e-mail message might contain
an attached text file or a downloaded webpage. Attached documents
need to be preserved as intended in the transmission, without
modification.
The composing MUA MUST NOT add a Legacy Display element to any part
of the message that is not a main body part. In particular, if a
part is annotated with Content-Disposition: attachment, or if it does
not descend via the first child of any of its multipart/mixed or
multipart/related ancestors, it is not a main body part, and MUST NOT
be modified.
See [I-D.ietf-lamps-e2e-mail-guidance] for more guidance about common
ways to distinguish main body parts from other MIME parts in a
message.
2.3.3.4. Do Not Add a Legacy Display Element to Other Content-Types
The purpose of injecting a Legacy Display element into each Main Body The purpose of injecting a Legacy Display element into each Main Body
MIME part is to enable rendering of otherwise obscured headers in MIME part is to enable rendering of otherwise obscured header fields
legacy clients that are capable of message decryption, but don't know in legacy clients that are capable of message decryption, but don't
how to follow the rest of the guidance in this document. know how to follow the rest of the guidance in this document.
The authors are unaware of any legacy client that would render any The authors are unaware of any legacy client that would render any
MIME part type other than text/plain and text/html as the Main Body. MIME part type other than text/plain and text/html as the Main Body.
A generating MUA SHOULD NOT add a Legacy Display element to any MIME A generating MUA SHOULD NOT add a Legacy Display element to any MIME
part with any other Content-Type. part with any other Content-Type.
4.1.2.5. Choosing Between Wrapped Message and Injected Headers 2.3.4. Composing with "Wrapped Message" Header Protection
When composing a message with end-to-end cryptographic protections, The Wrapped Message header protection scheme is briefly documented in
an MUA SHOULD protect the headers of that message as well as the Section 3.1 [RFC8551]. This section provides a more detailed
body. explanation of how to build such a message, and augments it with the
forwarded parameter as described in
[I-D.melnikov-iana-reg-forwarded].
An MUA MAY protect the headers of any outbound message using either To compose a message using "Wrapped Message" header protection, we
the "Wrapped Message" or the "Injected Headers" style of protection. use those inputs described in Section 2.3.1 plus the Header
See Section 4.2 for more discussion about reasons to choose one Confidentiality Policy hcp defined in Section 2.3.2. The new
mechanism or another. algorithm is:
[[ TODO: this document should recommend generation of one particular * For header field name and value (h,v) in origheaders:
scheme by default for new implementers ]]
4.1.3. Default Header Confidentiality Policy - Add header field h of origbody with value v
* If any of the header fields in origbody, including header fields
in the nested internal MIME structure, contain any 8-bit UTF-8
characters (see section section 3.7 of [RFC6532]):
- Let payload be a new MIME part with one header field: Content-
Type: message/global; forwarded=no, and whose body is origbody.
* Else:
- Let payload be a new MIME part with one header field: Content-
Type: message/rfc822; forwarded=no, and whose body is origbody.
* Apply crypto to payload, yielding MIME tree output
* If crypto contains encryption:
- Create new empty list of header field names and values newh
- For header field name and value (h,v) in origheaders:
o Let newval be hcp(h,v)
o If newval is not null:
+ Append (h,newval) to newh
- Set origheaders to newh
* For header field name and value (h,v) in origheaders:
- Add header field h of output with value v
* Return output
Note that the Header Confidentiality Policy hcp is ignored if crypto
does not contain encryption. This is by design.
2.3.5. Choosing Between Wrapped Message and Injected Headers
When composing a message with end-to-end cryptographic protections,
an MUA SHOULD protect the header fields of that message as well as
the body, using one of the formats described here.
A compatible MUA MUST be capable of generating a message with header
protection using the Injected Headers Section 2.3.3 format.
2.4. Default Header Confidentiality Policy
An MUA SHOULD have a sensible default Header Confidentiality Policy, An MUA SHOULD have a sensible default Header Confidentiality Policy,
and SHOULD NOT require the user to select one. and SHOULD NOT require the user to select one.
The default Header Confidentiality Policy SHOULD provide The default Header Confidentiality Policy SHOULD provide
confidentiality for the Subject header field by replacing it with the confidentiality for the Subject header field by replacing it with the
literal string [...]. Most users treat the Subject of a message 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 same way that they treat the body, and they are surprised to find
that the Subject of an encrypted message is visible. that the Subject of an encrypted message is visible.
[[ TODO: select one of the two policies below the recommended default [[ TODO: select one of the two policies below the recommended default
]] ]]
4.1.3.1. Minimalist Header Confidentiality Policy 2.4.1. Minimalist Header Confidentiality Policy
Accordingly, the most conservative recommended Header Confidentiality Accordingly, the most conservative recommended Header Confidentiality
Policy only protects the Subject: Policy only protects the Subject:
hcp_minimal(name, val_in) → val_out: hcp_minimal(name, val_in) → val_out:
if name is 'Subject': if name is 'Subject':
return '[...]' return '[...]'
else: else:
return val_in return val_in
4.1.3.2. Strong Header Confidentiality Policy 2.4.2. Strong Header Confidentiality Policy
Alternately, a more aggressive (and therefore more privacy- Alternately, a more aggressive (and therefore more privacy-
preserving) Header Confidentiality Policy only leaks a handful of preserving) Header Confidentiality Policy only leaks a handful of
fields whose absence is known to increase rates of delivery failure, fields whose absence is known to increase rates of delivery failure,
and simultaneously obscures the Message-ID behind a random new one: and simultaneously obscures the Message-ID behind a random new one:
hcp_strong(name, val_in) → val_out: hcp_strong(name, val_in) → val_out:
if name in ['From', 'To', 'Cc', 'Date']: if name in ['From', 'To', 'Cc', 'Date']:
return val_in return val_in
else if name is 'Subject': else if name is 'Subject':
return '[...]' return '[...]'
else if name is 'Message-ID': else if name is 'Message-ID':
return generate_new_message_id() return generate_new_message_id()
else: else:
return null return null
The function generate_new_message_id() represents whatever process The function generate_new_message_id() represents whatever process
the MUA typically uses to generate a Message-ID for a new outbound the MUA typically uses to generate a Message-ID for a new outbound
message. message.
4.1.3.3. Offering Stronger Header Confidentiality 2.4.3. Offering Stronger Header Confidentiality
A MUA MAY offer even stronger confidentiality for headers of an A MUA MAY offer even stronger confidentiality for header fields of an
encrypted message than described in Section 4.1.3.2. For example, it encrypted message than described in Section 2.4.2. For example, it
might implement an HCP that obfuscates the From field, or omits the might implement an HCP that obfuscates the From field, or omits the
Cc field, or ensures Date is represented in UTC (obscuring the local Cc field, or ensures Date is represented in UTC (obscuring the local
timezone). timezone).
The authors of this document hope that implementers with deployment The authors of this document hope that implementers with deployment
experience will document their chosen Header Confidentiality Policy experience will document their chosen Header Confidentiality Policy
and the rationale behind their choice. and the rationale behind their choice.
4.1.4. Receiving Side 2.5. Receiving Side
An MUA that receives a cryptographically-protected e-mail will render An MUA that receives a cryptographically-protected e-mail will render
it for the user. it for the user.
The receiving MUA will render the message body, a selected subset of The receiving MUA will render the message body, a selected subset of
header fields, and (as described in header fields, and (as described in
[I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the [I-D.ietf-lamps-e2e-mail-guidance]) provide a summary of the
cryptographic properties of the message. cryptographic properties of the message.
Most MUAs only render a subset of header fields by default. For Most MUAs only render a subset of header fields by default. For
example, few MUAs typically render Message-Id or Received header example, few MUAs typically render Message-Id or Received header
fields for the user, but most do render From, To, Cc, Date, and fields for the user, but most do render From, To, Cc, Date, and
Subject. Subject.
A MUA that knows how to handle a message with protected headers makes A MUA that knows how to handle a message with header protection makes
the following two changes to its behavior when rendering a message: the following two changes to its behavior when rendering a message:
* If it detects that an incoming message had protected headers, it * If it detects that an incoming message had protected header
renders header fields for the message from the protected headers, fields, it renders header fields for the message from the
ignoring the external (unprotected) headers. protected header fields, ignoring the external (unprotected)
header fields.
* It includes information in the message's cryptographic summary to * It includes information in the message's cryptographic summary to
indicate the types of protection that applied to each rendered indicate the types of protection that applied to each rendered
header field (if any). header field (if any).
A MUA that handles protected headers does _not_ need to render any A MUA that handles a message with header protection does _not_ need
new header fields that it did not render before. to render any new header fields that it did not render before.
4.1.4.1. Identifying that a Message has Protected Headers 2.5.1. Identifying that a Message has Header Protection
An incoming message can be identified as having protected headers An incoming message can be identified as having header protection
based on one of two signals: based on one of two signals:
* The Cryptographic Payload has Content-Type: message/rfc822 or * The Cryptographic Payload has Content-Type: message/rfc822 or
Content-Type: message/global and the parameter forwarded has a Content-Type: message/global and the parameter forwarded has a
value of no. See Section 4.1.4.3 for rendering guidance. value of no. See Section 2.5.4 for rendering guidance.
* The Cryptographic Payload has some other Content-Type and it has * The Cryptographic Payload has some other Content-Type and it has
parameter protected-headers set to v1. See Section 4.1.4.4 for parameter protected-headers set to v1. See Section 2.5.3 for
rendering guidance. rendering guidance.
Messages of both types exist in the wild, and a sensible MUA should Messages of both types exist in the wild, and a compliant MUA MUST be
be able to handle them both. They provide the same semantics and the able to handle them both. They provide the same semantics and the
same meaning. same meaning.
4.1.4.2. Updating the Cryptographic Summary 2.5.2. Updating the Cryptographic Summary
Regardless of whether a cryptographically-protected message has Regardless of whether a cryptographically-protected message has
protected headers, the cryptographic summary of the message should be protected header fields, the cryptographic summary of the message
modified to indicate what protections the headers have. should be modified to indicate what protections the header fields
have.
Each header individually has exactly one the following protections: Each header field individually has exactly one the following
protections:
* unprotected (this is the case for all headers in messages that * unprotected (this is the case for all header fields in messages
have no protected headers) that have no header protection)
* signed-only (bound into the same validated signature as the * signed-only (bound into the same validated signature as the
enclosing message, but also visible in transit) enclosing message, but also visible in transit)
* encrypted-only (only appears within the cryptographic payload; the * encrypted-only (only appears within the cryptographic payload; the
corresponding external header was either omitted or obfuscated) corresponding external header field was either omitted or
obfuscated)
* encrypted-and-signed (same as encrypted, but additionally is under * signed-and-encrypted (same as encrypted-only, but additionally is
a validatd signature) under a validated signature)
Note that while the message itself may be encrypted-and-signed, some Note that while the message itself may be signed-and-encrypted, some
headers may be replicated on the outside of the message (e.g. Date) header fields may be replicated on the outside of the message (e.g.
Those headers would be signed-only, despite the message itself being Date). Those header fields would be signed-only, despite the message
encrypted-and-signed. itself being signed-and-encrypted.
Rendering this information is likely to be complex and messy --- Rendering this information is likely to be complex and messy ---
users may not understand it. It is beyond the scope of this document users may not understand it. It is beyond the scope of this document
to suggest any specific graphical affordances or user experience. to suggest any specific graphical affordances or user experience.
Future work should include examples of successful rendering of this Future work should include examples of successful rendering of this
information. information.
4.1.4.3. Rendering a Wrapped Message 2.5.3. Rendering a Message with Injected Headers
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 When the Cryptographic Payload does not have a Content-Type of
message/rfc822 or message/global, and the parameter protected-headers message/rfc822 or message/global, and the parameter protected-headers
is set to v1, the values of the protected headers are drawn from the is set to v1, the values of the protected header fields are drawn
headers of the Cryptographic Payload, and the body that is rendered from the header fields of the Cryptographic Payload, and the body
is the Cryptographic Payload itself. that is rendered is the Cryptographic Payload itself.
4.1.4.4.1. Example Signed-only Message with Injected Headers 2.5.3.1. Example Signed-only Message with Injected Headers
L └─╴application/pkcs7-mime; smime-type="signed-data" A └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
M └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] B └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
N ├─╴text/plain C ├─╴text/plain
O └─╴text/html D └─╴text/html
The message body should be rendered the same way as this message: The message body should be rendered the same way as this message:
M └┬╴multipart/alternative B └┬╴multipart/alternative
N ├─╴text/plain C ├─╴text/plain
O └─╴text/html D └─╴text/html
It should render header fieldss taken from part M. It should render header fields taken from part B.
Its cryptographic summary should indicates that the message was Its cryptographic summary should indicate that the message was signed
signed and all rendered header fields were included in the signature. and all rendered header fields were included in the signature.
The MUA SHOULD ignore header fields from part L for the purposes of The MUA SHOULD ignore header fields from part A for the purposes of
rendering. rendering.
4.1.4.4.2. Example Signed-and-Encrypted Message with Injected Headers 2.5.3.2. Example Signed-and-Encrypted Message with Injected Headers
Consider a message with this structure, where the MUA is able to Consider a message with this structure, where the MUA is able to
validate the cryptographic signature: validate the cryptographic signature:
P └─╴application/pkcs7-mime; smime-type="enveloped-data" E └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to) ↧ (decrypts to)
Q └─╴application/pkcs7-mime; smime-type="signed-data" F └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to) ⇩ (unwraps to)
R └┬╴multipart/alternative [Cryptographic Payload + Rendered Body] G └┬╴multipart/alternative [Cryptographic Payload + Rendered Body]
S ├─╴text/plain H ├─╴text/plain
T └─╴text/html I └─╴text/html
The message body should be rendered the same way as this message: The message body should be rendered the same way as this message:
R └┬╴multipart/alternative G └┬╴multipart/alternative
S ├─╴text/plain H ├─╴text/plain
T └─╴text/html I └─╴text/html
It should render headers taken from part R. It should render header fields taken from part G.
Its cryptographic summary should indicates that the message was Its cryptographic summary should indicate that the message was signed
signed and encrypted. As in Section 4.1.4.3.2, each rendered header and encrypted. As in Section 2.5.4.2, each rendered header field
field found in R should be compared against the header field of the found in G should be compared against the header field of the same
same name from P. If the value found in P matches the value found in name from E. If the value found in E matches the value found in G,
R, the header field should be marked as signed-only. If no matching 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 header field was found in E, or the value found did not match the
value from R, the header field should be marked as signed-and- value from G, the header field should be marked as signed-and-
encrypted. encrypted.
4.1.4.4.3. Do Not Render Legacy Display Elements 2.5.3.3. Do Not Render Legacy Display Elements
As described in FIXME:SECTION_REFERENCE, a message with cryptographic As described in Section 2.1, a message with cryptographic
confidentiality protection MAY include "Legacy Display" elements for confidentiality protection MAY include "Legacy Display" elements for
backward-compatibility with legacy MUAs. These Legacy Display backward-compatibility with legacy MUAs. These Legacy Display
elements are strictly decorative, unambiguously identifiable, and elements are strictly decorative, unambiguously identifiable, and
will be discarded by compliant implementations. will be discarded by compliant implementations.
The receiving MUA SHOULD avoid rendering the identified Legacy The receiving MUA SHOULD avoid rendering the identified Legacy
Display elements to the user at all, since it is aware of and can Display elements to the user at all, since it is aware of header
render the actual Protected Headers. protection and can render the actual protected header fields.
If a text/html or text/plain part within the cryptographic envelope If a text/html or text/plain part within the cryptographic envelope
is identified as containing Legacy Display elements, those elements is identified as containing Legacy Display elements, those elements
should be hidden when rendering or generating a draft reply. should be hidden when rendering or generating a draft reply.
4.1.4.4.3.1. Identifying a Part with Legacy Display Elements 2.5.3.3.1. Identifying a Part with Legacy Display Elements
A receiving MUA acting on a message that contains an encrypting A receiving MUA acting on a message that contains an encrypting
Cryptographic Layer identifies a MIME subpart with within the Cryptographic Layer identifies a MIME subpart with within the
Cryptographic Payload as containing Legacy Display elements based on Cryptographic Payload as containing Legacy Display elements based on
the Content-Type of the subpart. the Content-Type of the subpart.
* The subpart's Content-Type contains a parameter hp-legacy-display * The subpart's Content-Type contains a parameter hp-legacy-display
with value set to 1 with value set to 1
* The subpart's Content-Type is either text/html (see * The subpart's Content-Type is either text/html (see
Section 4.1.4.4.3.3) or text/plain (see Section 4.1.4.4.3.2) Section 2.5.3.3.3) or text/plain (see Section 2.5.3.3.2)
Note that the term "subpart" above is used in the general sense: if Note that the term "subpart" above is used in the general sense: if
the Cryptographic Payload is a single part, that part itself may the Cryptographic Payload is a single part, that part itself may
contain a Legacy Display element if it is marked with the hp-legacy- contain a Legacy Display element if it is marked with the hp-legacy-
display=1 parameter. display=1 parameter.
4.1.4.4.3.2. Omitting Legacy Display Elements from text/plain 2.5.3.3.2. Omitting Legacy Display Elements from text/plain
If a text/plain part within the Cryptographic Payload has the If a text/plain part within the Cryptographic Payload has the
Content-Type parameter hp-legacy-display="1", it should be processed Content-Type parameter hp-legacy-display="1", it should be processed
before rendering in the following fashion: before rendering in the following fashion:
* Discard the leading lines of the body of the part up to and * Discard the leading lines of the body of the part up to and
including the first entirely blank line. including the first entirely blank line.
Note that implementing this strategy is depenent on the charset used Note that implementing this strategy is dependent on the charset used
by the MIME part. by the MIME part.
See Appendix E.1 for an example. See Appendix D.1 for an example.
4.1.4.4.3.3. Omitting Legacy Display Elements from text/html 2.5.3.3.3. Omitting Legacy Display Elements from text/html
If a text/html part within the Cryptographic Payload has the Content- If a text/html part within the Cryptographic Payload has the Content-
Type parameter hp-legacy-display="1", it should be processed before Type parameter hp-legacy-display="1", it should be processed before
rendering in the following fashion: rendering in the following fashion:
* If any element of the HTML <body> is a <div> with class attribute * If any element of the HTML <body> is a <div> with class attribute
header-protecton-legacy-display, that entire element should be header-protection-legacy-display, that entire element should be
omitted. omitted.
A straightforward way for an HTML-capable MUA to do this is to add an A straightforward way for an HTML-capable MUA to do this is to add an
entry to the [CSS] stylesheet for such a part: entry to the [CSS] stylesheet for such a part:
body div.header-protection-legacy-display:firstchild { display: none; } body div.header-protection-legacy-display { display: none; }
4.1.4.5. Affordances for Debugging and Troubleshooting 2.5.4. Rendering a Wrapped Message
Some MUAs may compose and send a message with end-to-end
cryptographic protections that offer header protection using the
Wrapped Message scheme described in Section 3.1 of [RFC8551]. This
section describes how a receiving MUA should identify and render such
a 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 header fields are drawn from the header fields of
the Cryptographic Payload, and the body that is rendered is the body
of the Cryptographic Payload.
2.5.4.1. Example Signed-Only Wrapped Message
Consider a message with this structure, where the MUA is able to
validate the cryptographic signature:
J └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
K └┬╴message/rfc822 [Cryptographic Payload]
L └┬╴multipart/alternative [Rendered Body]
M ├─╴text/plain
N └─╴text/html
The message body should be rendered the same way as this message:
L └┬╴multipart/alternative
M ├─╴text/plain
N └─╴text/html
It should render header fields taken from part K.
Its cryptographic summary should indicate that the message was signed
and all rendered header fields were included in the signature.
The MUA SHOULD ignore header fields from part J for the purposes of
rendering.
2.5.4.2. Example Signed-and-Encrypted Wrapped Message
Consider a message with this structure, where the MUA is able to
validate the cryptographic signature:
O └─╴application/pkcs7-mime; smime-type="enveloped-data"
↧ (decrypts to)
P └─╴application/pkcs7-mime; smime-type="signed-data"
⇩ (unwraps to)
Q └┬╴message/rfc822 [Cryptographic Payload]
R └┬╴multipart/alternative [Rendered Body]
S ├─╴text/plain
T └─╴text/html
The message body should be rendered the same way as this message:
R └┬╴multipart/alternative
S ├─╴text/plain
T └─╴text/html
It should render header fields taken from part Q.
Its cryptographic summary should indicate that the message was signed
and encrypted. Each rendered header field found in Q should be
compared against the header field of the same name from O. If the
value found in O matches the value found in Q, the header field
should be marked as signed-only. If no matching header field was
found in O, or the value found did not match the value from Q, the
header field should be marked as signed-and-encrypted.
2.5.5. Guidance for Automated Message Handling
Some automated systems have a control channel that is operated by
e-mail. For example, an incoming e-mail message could subscribe
someone to a mailing list, initiate the purchase of a specific
product, approve another message for redistribution, or adjust the
state of some shared object.
To the extent that such a system depends on end-to-end cryptographic
guarantees about the e-mail control message, header protection as
described in this document should improve the system's security.
This section provides some specific guidance for systems that use
e-mail messages as a control channel that want to benefit from these
security improvements.
2.5.5.1. Interpret Only Protected Header Fields
Consider the situation where an e-mail-based control channel depends
on the message's cryptographic signature and the action taken depends
on some header field of the message.
In this case, the automated system MUST rely on information from the
header field that is protected by the mechanism described in this
document. It MUST NOT rely on any header field found outside the
cryptographic payload.
For example, consider an administrative interface for a mailing list
manager that only accepts control messages that are signed by one of
its administrators. When an inbound message for the list arrives, it
is queued (waiting for administrative approval) and the system
generates and listens for two distinct e-mail addresses related to
the queued message -- one that approves the message, and one that
rejects it. If an administrator sends a signed control message to
the approval address, the mailing list verifies that the protected
To: header field of the signed control message contains the approval
address before approving the queued message for redistribution. If
the protected To: header field does not contain that address, or
there is no protected To: header field, then the mailing list logs or
reports the error, and does not act on that control message.
2.5.5.2. Ignore Legacy Display Elements
Consider the situation where an e-mail based control channel expects
to receive an end-to-end encrypted message -- for example, where the
control messages need confidentiality guarantees -- and where the
action taken depends on the contents of some MIME part within message
body.
In this case, the automated system that decrypts the incoming mssages
and scans the relevant MIME part SHOULD identify when the MIME part
contains a legacy display element (see Section 2.5.3.3.1), and it
SHOULD parse the relevant MIME part with the legacy display element
removed.
For example, consider an administrative interface of a confidential
issue tracking software. An authorized user can confidentially
adjust the status of a tracked issue by a specially-formatted first
line of the message body (for example, severity #183 serious). When
the user's MUA encrypts a plain text control message to this issue
tracker, depending on the MUA's HCP and its choice of legacy value,
it may add a legacy display element. If it does so, then the first
line of the message body will contain a decorative copy of the
confidential Subject: header field. The issue tracking software
decrypts the incoming control message, identifies that there is a
legacy display element in the part (see Section 2.5.3.3.1), strips
the legacy display lines (including the first blank line), and only
then parses the remaining top line to look for the expected special
formatting.
2.5.6. Affordances for Debugging and Troubleshooting
Note that advanced users of an MUA may need access to the original Note that advanced users of an MUA may need access to the original
message, for example to troubleshoot problems with the MUA itself, or message, for example to troubleshoot problems with the MUA itself, or
problems with the SMTP transport path taken by the message. problems with the SMTP transport path taken by the message.
A MUA that applies these rendering guidelines SHOULD ensure that the A MUA that applies these rendering guidelines SHOULD ensure that the
full original source of the message as it was received remains full original source of the message as it was received remains
available to such a user for debugging and troubleshooting. available to such a user for debugging and troubleshooting.
4.1.4.6. Composing a Reply to an Encrypted Message with Protected 2.5.7. Rendering Other Schemes
Headers
When composing a reply to an encrypted message with protected Other MUAs may have generated different structures of messages that
headers, the MUA is acting both as a receiving MUA and as a sending aim to offer end-to-end cryptographic protections that include header
MUA. Special guidance applies here, as things can go wrong in at protection.
least two ways: leaking previously-confidential information, and
replying to the wrong party.
4.1.4.6.1. Avoid Leaking Encrypted Headers in Reply While this document is not normative for those schemes, it offers
guidance for how to identify and handle these other formats. In the
following a list of systems that are known to generate email messages
with end-to-end cryptographic protections that include header
protection using a different MIME scheme.
2.5.7.1. Pretty Easy Privacy (pEp)
The pEp (pretty Easy privacy) [I-D.pep-general] project specifies
MIME schemes for Signed-and-Encrypted email messages that also
provide header protection [I-D.pep-email]. Similar to the "Wrapped
Messages" scheme described in Section 2.3.4 and Section 2.5.4, pEp
email messages are fully encapsulated in the Cryptographic Payload.
More information can be found in [I-D.pep-email].
2.5.8. Composing a Reply to an Encrypted Message with Header Protection
When composing a reply to an encrypted message with header
protection, 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.
2.5.8.1. Avoid Leaking Encrypted Headers in Reply
As noted in [I-D.ietf-lamps-e2e-mail-guidance], an MUA in this As noted in [I-D.ietf-lamps-e2e-mail-guidance], an MUA in this
position MUST NOT leak previously-encrypted content in the clear in a position MUST NOT leak previously-encrypted content in the clear in a
followup message. The same is true for protected headers. followup message. The same is true for protected header fields.
Values from any header field that was identified as either encrypted Values from any header field that was identified as either encrypted
or signed-and-encrypted based on the steps outlined above MUST NOT be or signed-and-encrypted based on the steps outlined above MUST NOT be
placed in cleartext output when generating a message. placed in cleartext output when generating a message.
In particular, if Subject was encrypted, and it is copied into the In particular, if Subject was encrypted, and it is copied into the
draft encrypted reply, the replying MUA MUST obfuscate the Subject draft encrypted reply, the replying MUA MUST obfuscate the
field in the cleartext header as described above. unprotected (cleartext) Subject header field as described above.
[[ TODO: formally describe how a replying MUA should generate a [[ TODO: formally describe how a replying MUA should generate a
message-specific Header Protection policy based on the cryptographic message-specific Header Protection policy based on the cryptographic
status of the headers of the incoming message ]] status of the headers of the incoming message ]]
4.1.4.6.2. Avoid Misdirected Replies to Encrypted Messages with 2.5.8.2. Avoid Misdirected Replies to Encrypted Messages with Header
Protected Headers Protection
When replying to a message, the Composing MUA typically decides who When replying to a message, the Composing MUA typically decides who
to send the reply to based on: to send the reply to based on:
* the Reply-To, Mail-Followup-To, or From headers * the Reply-To, Mail-Followup-To, or From header fields
* optionally, the other To or Cc headers (if the user chose to * optionally, the other To or Cc header fields (if the user chose to
"reply all") "reply all")
When a message has protected headers, the replying MUA MUST populate When a message has header protection, the replying MUA MUST populate
the destination fields of the draft message using the protected the destination fields of the draft message using the protected
headers, and ignore any unprotected headers. header fields, and ignore any unprotected header fields.
This mitigates against an attack where Mallory gets a copy of an This mitigates against an attack where Mallory gets a copy of an
encrypted message from Alice to Bob, and then replays the message to 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 Bob with an additional Cc to Mallory's own e-mail address in the
message's outer header. message's outer (unprotected) header section.
If Bob knows Mallory's certificate already, and he replies to such a If Bob knows Mallory's certificate already, and he replies to such a
message without following the guidance in this section, it's likely message without following the guidance in this section, it's likely
that his MUA will encrypt the cleartext of the message directly to that his MUA will encrypt the cleartext of the message directly to
Mallory. Mallory.
4.1.4.7. Implicitly-rendered Header Fields 2.5.9. Implicitly-rendered Header Fields
While From and To and Cc and Subject and Date are often explicitly While From and To and Cc and Subject and Date are often explicitly
rendered to the user, some header fields do affect message display, rendered to the user, some header fields do affect message display,
without being explicitly rendered. without being explicitly rendered.
For example, Message-Id, References, and In-Reply-To header fields For example, Message-Id, References, and In-Reply-To header fields
may collectively be used to place a message in a "thread" or series may collectively be used to place a message in a "thread" or series
of messages. of messages.
In another example, Section 4.1.4.6.2 observes that the value of the In another example, Section 2.5.8.2 observes that the value of the
Reply-To field can influence the draft reply message. So while 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 user may never see the Reply-To header field directly, it is
"rendered" when the user interacts with the message by replying to implicitly "rendered" when the user interacts with the message by
it. replying to it.
An MUA that depends on any implicitly-rendered header field in a An MUA that depends on any implicitly-rendered header field in a
message with protected headers SHOULD use the value from the message with header protection SHOULD use the value from the
protected header, and SHOULD NOT use any value found outside the protected header field, and SHOULD NOT use any value found outside
cryptographic protection. the cryptographic protection.
4.1.4.8. Unprotected Headers Added in Transit 2.5.10. Unprotected Header Fields Added in Transit
Some headers are legitimately added in transit, and could not have Some header fields are legitimately added in transit, and could not
been known to the sender at message composition time. have been known to the sender at message composition time.
The most common of these headers are Received and DKIM-Signature, The most common of these header fields are Received and DKIM-
neither of which are typically rendered, either explicitly or Signature, neither of which are typically rendered, either explicitly
implicitly. or implicitly.
If a receiving MUA has specific knowledge about a given header field, If a receiving MUA has specific knowledge about a given header field,
including that: including that:
* the header field would not have been known to the original sender, * the header field would not have been known to the original sender,
and and
* the header field might be rendered explicitly or implicitly, * the header field might be rendered explicitly or implicitly,
then the MUA MAY decide to operate on the value of that header field then the MUA MAY decide to operate on the value of that header field
from the unprotected header section, even though the message has from the unprotected header section, even though the message has
protected headers. header protection.
The MUA MAY prefer to verify that the headers in question have The MUA MAY prefer to verify that the header fields in question have
additional transit-derived cryptographic protections (e.g., to test additional transit-derived cryptographic protections (e.g., to test
whether they are covered by a valid DKIM-Signature) before rendering whether they are covered by a valid DKIM-Signature, see [RFC6376])
or acting on them. before rendering or acting on them.
Specific examples appear below. Specific examples appear below.
4.1.4.8.1. Mailing list headers: List-* and Archived-At 2.5.10.1. Mailing list header fields: List-* and Archived-At
If the message arrives through a mailing list, the list manager If the message arrives through a mailing list, the list manager
itself may inject headers (most of which start with List-) in the itself may inject header fields (most of which start with List-) in
message: the message:
* List-Archive * List-Archive
* List-Subscribe * List-Subscribe
* List-Unsubscribe * List-Unsubscribe
* List-Id * List-Id
* List-Help * List-Help
* List-Post * List-Post
* Archived-At * Archived-At
skipping to change at page 33, line 14 skipping to change at page 31, line 41
* List-Unsubscribe * List-Unsubscribe
* List-Id * List-Id
* List-Help * List-Help
* List-Post * List-Post
* Archived-At * Archived-At
For some MUAs, these headers are implicitly rendered, by providing For some MUAs, these header fields are implicitly rendered, by
buttons for actions like "Subscribe", "View Archived Version", "Reply providing buttons for actions like "Subscribe", "View Archived
List", "List Info", etc. Version", "Reply List", "List Info", etc.
An MUA that receives a message with protected headers that contains An MUA that receives a message with header protection that contains
these header fields in the unprotected section, and that has reason these header fields in the unprotected section, and that has reason
to believe the message is coming through a mailing list MAY decide to to believe the message is coming through a mailing list MAY decide to
render them to the user (explicitly or implicitly) even though they render them to the user (explicitly or implicitly) even though they
are not protected. are not protected.
FIXME: other examples of unprotected transit headers? FIXME: other examples of unprotected transit header fields?
4.2. Backward Compatibility Use Cases 3. E-mail Ecosystem Evolution
4.2.1. Receiving Side MIME-Conformant This document is intended to offer tooling needed to improve the
state of the e-mail ecosystem in a way that can be deployed without
significant disruption. Some elements of this specification are
present for transitional purposes, but would not exist if the system
were designed from scratch.
This section applies to the case where the sending side (fully) This section describes these transitional mechanisms, as well as some
supports Header Protection as specified in this document, while the suggestions for how they might eventually be phased out.
receiving side does not support this specification, but is MIME-
conformant according to [RFC2045], ff. (cf. Section 3.1.2 and
Section 3.1.2.1)
The sending side specification of the main use case (cf. 3.1. Dropping Legacy Display Elements
Section 4.1) MUST ensure that receiving sides can still recognize and
display or offer to display the encapsulated data in accordance with
its media type (cf. [RFC2049], Section 2). In particular, receiving
sides that do not support this specification, but are MIME-conformant
according to [RFC2045], ff. can still recognize and display the
Message intended for the user.
[[ TODO: Verify once solution is stable and update last sentence. ]] Any decorative Legacy Display element added to an encrypted message
that uses the Injected Header scheme is present strictly for enabling
header field visibility (most importantly, the Subject header field)
when the message is viewed with a decryption-capable legacy client.
4.2.2. Receiving Side Not MIME-Conformant Eventually, the hope is that most decryption-capable MUAs will
conform to this specification, and there will be no need for
injection of Legacy Display elements in the message body. A survey
of widely-used decryption-capable MUAs might be able to establish
when most of them do support this specification.
This section applies to cases where the sending side (fully) supports At that point, a composing MUA could make the legacy parameter
Header Protection as specified in this document, while the receiving described in {#compose-injected-headers} to false by default, or
side neither supports this specification *nor* is MIME-conformant could even hard-code it to false, yielding a much simpler message
according to [RFC2045], ff. (cf. Section 3.1.2 and Section 3.1.2.2). construction set.
Another variant of backward compatibility has been implemented by pEp Until that point, an end user might want to signal that their
[I-D.pep-email], i.e. pEp Email Format 1.0. At this time pEp has receiving MUAs are conformant to this draft so that a peer composing
implemented this for PGP/MIME, but not yet S/MIME. a message to them can set legacy to false. A signal indicating
capability of handling messages with header protection might be
placed in the user's cryptographic certificate, or in outbound
messages.
5. Usability Considerations This draft doesn't attempt to define the syntax or semantics of such
a signal.
4. Usability Considerations
This section describes concerns for MUAs that are interested in easy This section describes concerns for MUAs that are interested in easy
adoption of header protection by normal users. adoption of header protection by normal users.
While they are not protocol-level artifacts, these concerns motivate While they are not protocol-level artifacts, these concerns motivate
the protocol features described in this document. the protocol features described in this document.
See also the Usability section in [I-D.ietf-lamps-e2e-mail-guidance]. See also the Usability section in [I-D.ietf-lamps-e2e-mail-guidance].
5.1. Mixed Protections Within a Message Are Hard To Understand 4.1. Mixed Protections Within a Message Are Hard To Understand
[[ TODO ]] [[ TODO ]]
5.2. Users Should Not Have To Choose a Header Confidentiality Policy 4.2. Users Should Not Have To Choose a Header Confidentiality Policy
[[ TODO ]] [[ TODO ]]
6. Security Considerations 4.3. Users Should Not Have To Choose a Header Protection Scheme
[[ TODO ]] [[ TODO ]]
7. Privacy Considerations 5. Security Considerations
[[ TODO ]] [[ TODO ]]
8. IANA Considerations 6. Privacy Considerations
[[ TODO ]]
7. 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. ]]
9. Acknowledgments 8. 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, Bernhard E. Reiter, Claudio Luck, David Wilson, Hernani Alp, Bernhard E. Reiter, Claudio Luck, David Wilson, Hernani
Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Robert Marques, juga, Krista Bennett, Kelly Bristol, Lars Rohwedder, Robert
Williams, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and Williams, Russ Housley, Sofia Balicka, Steve Kille, Volker Birk, and
Wei Chuang. Wei Chuang.
10. References 9. References
10.1. Normative References 9.1. Normative References
[I-D.ietf-lamps-e2e-mail-guidance] [I-D.ietf-lamps-e2e-mail-guidance]
Gillmor, D. K., "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-ietf-lamps-e2e- Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-
mail-guidance-02, 25 January 2022, mail-guidance-02, 25 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-lamps-e2e- <https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-
mail-guidance-02.txt>. mail-guidance-02.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
skipping to change at page 35, line 30 skipping to change at page 34, line 23
[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>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
10.2. Informative References 9.2. Informative References
[CSS] World Wide Web Consortium, "Cascading Style Sheets Level 2 [CSS] World Wide Web Consortium, "Cascading Style Sheets Level 2
Revision 2 (CSS 2.2) Specification", 12 April 2016, Revision 2 (CSS 2.2) Specification", 12 April 2016,
<https://www.w3.org/TR/2016/WD-CSS22-20160412/>. <https://www.w3.org/TR/2016/WD-CSS22-20160412/>.
[I-D.ietf-lamps-samples] [I-D.ietf-lamps-samples]
Gillmor, D. K., "S/MIME Example Keys and Certificates", Gillmor, D. K., "S/MIME Example Keys and Certificates",
Work in Progress, Internet-Draft, draft-ietf-lamps- Work in Progress, Internet-Draft, draft-ietf-lamps-
samples-07, 13 December 2021, samples-08, 2 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-lamps-samples- <https://www.ietf.org/archive/id/draft-ietf-lamps-samples-
07.txt>. 08.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, forwarded-00, 4 November 2019,
<https://www.ietf.org/archive/id/draft-melnikov-iana-reg- <https://www.ietf.org/archive/id/draft-melnikov-iana-reg-
forwarded-00.txt>. 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-01, 2 November 2020, email-01, 2 November 2020,
<https://www.ietf.org/archive/id/draft-pep-email-01.txt>. <https://www.ietf.org/archive/id/draft-pep-email-01.txt>.
[pEp.mixnet] [I-D.pep-general]
pEp Foundation, "Mixnet", June 2020, Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy
<https://dev.pep.foundation/Mixnet>. privacy (pEp): Privacy by Default", Work in Progress,
Internet-Draft, draft-pep-general-00, 3 March 2022,
<https://www.ietf.org/archive/id/draft-pep-general-
00.txt>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>.
[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>.
[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., [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",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>. 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. Possible Problems with some Legacy Clients Appendix A. Possible Problems with some Legacy Clients
skipping to change at page 38, line 17 skipping to change at page 36, line 50
* Appears as a forwarded message * Appears as a forwarded message
* Appears as an attachment * Appears as an attachment
* Security indicators not visible * Security indicators not visible
* User has multiple different methods to Reply: (e.g. reply to * User has multiple different methods to Reply: (e.g. reply to
outer, reply to inner) outer, reply to inner)
* User sees english "Subject:" in body despite message itself being * User sees English "Subject:" in body despite message itself being
in non-english in non-English
* Security indicators do not identify protection status of header * Security indicators do not identify protection status of header
fields fields
* Headers in body render with local header fields (e.g. showing * Header fields in body render with local header field names (e.g.
"Betreff" instead of "Subject") and dates (TZ, locale) showing "Betreff" instead of "Subject") and dates (TZ, locale)
A.3. Problems when Replying to a signed+encrypted Message A.3. Problems when Replying to a signed+encrypted Message
Note that the use case here is: Note that the use case here is:
* User views message, to the point where they can read it. * User views message, to the point where they can read it.
* User then replies to message, and they are shown a message * User then replies to message, and they are shown a message
composition window, which has some UI elements composition window, which has some UI elements
skipping to change at page 39, line 4 skipping to change at page 37, line 35
* protected subject is in UI:subject (and will leak) * protected subject is in UI:subject (and will leak)
* protected subject is quoted in UI:body * protected subject is quoted in UI:body
* protected subject is not anywhere in UI * protected subject is not anywhere in UI
* message body is _not_ visible/quoted in UI:body * message body is _not_ visible/quoted in UI:body
* user cannot reply while viewing protected message * user cannot reply while viewing protected message
* reply is not encrypted by default (but is for normal S/MIME * reply is not encrypted by default (but is for normal S/MIME
sign+enc messages) sign+enc messages)
* unprotected From: is in UI:To * unprotected From: is in UI:To
* User's locale (lang, TZ) leaks in quoted body * User's locale (lang, TZ) leaks in quoted body
* Headers not protected (and in particular, Subject is not obscured) * Header fields not protected (and in particular, Subject is not
by default obscured) by default
A.4. Problems Reviewing signed-only Messages in List View A.4. Problems Reviewing signed-only Messages in List View
* Unprotected Subject, Date, From, To are visible * Unprotected Subject, Date, From, To are visible
* Threading is not visible * Threading is not visible
A.5. Problems when Rendering a signed-only Message A.5. Problems when Rendering a signed-only Message
* Unprotected Subject is visible * Unprotected Subject is visible
skipping to change at page 39, line 46 skipping to change at page 38, line 31
* Nuisance alarms during user interaction * Nuisance alarms during user interaction
* Impossible to view message body * Impossible to view message body
* Appears as a forwarded message * Appears as a forwarded message
* Appears as an attachment * Appears as an attachment
* Security indicators not visible * Security indicators not visible
* Security indicators do not identify protection status of headers * Security indicators do not identify protection status of header
fields
* User has multiple different methods to Reply: (e.g. reply to * User has multiple different methods to Reply: (e.g. reply to
outer, reply to inner) outer, reply to inner)
* Headers in body render with local header fields (e.g. showing * Header fields in body render with local header fields (e.g.
"Betreff" instead of "Subject") and dates (TZ, locale) showing "Betreff" instead of "Subject") and dates (TZ, locale)
A.6. Problems when Replying to a signed-only Message A.6. Problems when Replying to a signed-only Message
This uses the same use case(s) and shorthand as Appendix A.3. This uses the same use case(s) and shorthand as Appendix A.3.
* Unprotected Subject: is in UI:subject * Unprotected Subject: is in UI:subject
* Protected Subject: is quoted in UI:body * Protected Subject: is quoted in UI:body
* Protected Subject: is not anywhere in UI * Protected Subject: is not anywhere in UI
skipping to change at page 162, line 22 skipping to change at page 160, line 22
a) One Message for each recipient in the Bcc header field a) One Message for each recipient in the Bcc header field
separately, with a Bcc header field containing only the address separately, with a Bcc header field containing only the address
of the recipient it is sent to. of the recipient it is sent to.
b) The same Message for each recipient in the Bcc header field b) The same Message for each recipient in the Bcc header field
with a Bcc header field containing an indication such as with a Bcc header field containing an indication such as
"Undisclosed recipients", but no addresses. "Undisclosed recipients", but no addresses.
c) The same Message for each recipient in the Bcc header field c) The same Message for each recipient in the Bcc header field
which does not include a Bcc header field (this Message is which does not include a Bcc header field (this Message is
identical to 1. / cf. above). identical to 1. / see above).
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 D. Text Moved from Above Appendix D. Examples
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
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
deleted, depending on the decision of the LAMPS WG.
D.1. MIME Format
Currently there are two options in discussion:
1. The option according to the current S/MIME specification (cf.
[RFC8551])
2. An alternative option that is based on the former "memory hole"
approach (cf. "Injected Headers" in this document)
D.1.1. S/MIME Specification
Note: This is currently described in the main part of this document.
D.1.1.1. Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
Hole")
An alternative option (based on the former autocrypt "Memory Hole"
approach) to be considered, is described here as "Injected Headers".
Unlike the option described in Appendix D.1.1, this option does not
use a "message/RFC822" wrapper to unambiguously delimit the Inner
Message.
Before choosing this option, the following two issues must be
assessed to ensure no interoperability issues result from it:
1. How current MIME parser implementations treat non-MIME Header
Fields, which are not part of the outermost MIME entity and not
part of a Message wrapped into a MIME entity of media type
"message/rfc822", and how such Messages are rendered to the user.
This draft provides some examples for testing this.
2. MIME-conformance, i.e. whether or not this option is (fully)
MIME-conformant [RFC2045] ff., in particular also Section 5.1. of
[RFC2046] on "Multipart Media Type). In the following an excerpt
of paragraphs that may be relevant in this context:
The only header fields that have defined meaning for body parts
are those the names of which begin with "Content-". All other
header fields may be ignored in body parts. Although they
should generally be retained if at all possible, they may be
discarded by gateways if necessary. Such other fields are
permitted to appear in body parts but must not be depended on.
"X-" fields may be created for experimental or private
purposes, with the recognition that the information they
contain may be lost at some gateways.
NOTE: The distinction between an RFC 822 Message and a body
part is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part
that contains an encapsulated Message, the body of which is a
JPEG image. In order to represent the latter, the body part
must have "Content-Type: message/rfc822", and its body (after
the blank line) must be the encapsulated Message, with its own
"Content-Type: image/jpeg" header field. The use of similar
syntax facilitates the conversion of Messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which
parts actually are Messages, a "digest" subtype is also
defined.)
The MIME structure of an Email Message looks as follows:
<Outer Message Header Section (unprotected)>
<Outer Message Body (protected)>
<Inner Message Header Section>
<Inner Message Body>
The following example demonstrates how an Original Message might be
protected, i.e., the Original Message is contained as Inner Message
in the Protected Body of an Outer Message. It illustrates the first
Body part (of the Outer Message) as a "multipart/signed"
(application/pkcs7-signature) media type:
Lines are prepended as follows:
* "O: " Outer Message Header Section
* "I: " Message Header Section
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
O: Subject: Meeting at my place
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
O: MIME-Version: 1.0
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
O: protocol="application/pkcs7-signature";
O: boundary=boundary-AM
This is a multipart message in MIME format.
--boundary-AM
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
I: MIME-Version: 1.0
I: MMHS-Primary-Precedence: 3
I: Subject: Meeting at my place
I: To: somebody@example.net
I: X-Mailer: Isode Harrier Web Server
I: Content-Type: text/plain; charset=us-ascii
This is an important message that I don't want to be modified.
--boundary-AM
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature
[[base-64 encoded signature]]
--boundary-AM--
The Outer Message Header Section is unprotected, while the remainder
(Outer Message Body) is protected. The Outer Message Body consists
of the Inner Message (Header Section and Body).
The Inner Message Header Section is the same as (or a subset of) the
Original Message Header Section.
The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any MIME structure.
D.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.
D.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 C.1). Certain MUAs cannot properly decrypt Messages with
Bcc recipients. ]]
D.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.
D.1.2.3. Cryptographic Layers / Envelope
[[ TODO: Basically refer to S/MIME standards ]]
D.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:
D.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 D.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 D.1.2.5.
D.1.2.4.2. Step 2: Compose the Outer Message Header Section
Depending on the decision in Appendix D.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 D.1.2.4.1).
D.1.2.4.3. Step 3: Apply Protection to the Original Message
Depending on the Protection Level selected in Appendix D.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 ]]
D.1.2.5. Outer Message Header Fields
D.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 C.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
D.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 E. Examples
This section offers example cryptographic payloads (the content This section offers example cryptographic payloads (the content
within the cryptographic envelope) that contain Legacy Display within the cryptographic envelope) that contain Legacy Display
elements. elements.
E.1. Example text/plain Cryptographic Payload with Legacy Display D.1. Example text/plain Cryptographic Payload with Legacy Display
Elements Elements
Here is a simple one-part Cryptographic Payload (headers and body) of Here is a simple one-part Cryptographic Payload (headers and body) of
a message that includes Legacy Display elements: a message that includes Legacy Display elements:
Date: Fri, 21 Jan 2022 20:40:48 -0500 Date: Fri, 21 Jan 2022 20:40:48 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
Subject: Dinner plans Subject: Dinner plans
Message-ID: <text-plain-legacy-display@lhp.example> Message-ID: <text-plain-legacy-display@lhp.example>
skipping to change at page 170, line 40 skipping to change at page 161, line 34
A legacy decryption-capable MUA that is unaware of this mechanism A legacy decryption-capable MUA that is unaware of this mechanism
will ignore the hp-legacy-display="1" parameter and instead render will ignore the hp-legacy-display="1" parameter and instead render
the body including the Legacy Display elements: the body including the Legacy Display elements:
Subject: Dinner plans Subject: Dinner plans
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
E.2. Example text/html Cryptographic Payload with Legacy Display D.2. Example text/html Cryptographic Payload with Legacy Display
Elements Elements
Here is a modern one-part Cryptographic Payload (headers and body) of Here is a modern one-part Cryptographic Payload (headers and body) of
a message that includes Legacy Display elements: a message that includes Legacy Display elements:
Date: Fri, 21 Jan 2022 20:40:48 -0500 Date: Fri, 21 Jan 2022 20:40:48 -0500
From: Alice <alice@example.net> From: Alice <alice@example.net>
To: Bob <bob@example.net> To: Bob <bob@example.net>
Subject: Dinner plans Subject: Dinner plans
Message-ID: <text-html-legacy-display@lhp.example> Message-ID: <text-html-legacy-display@lhp.example>
skipping to change at page 171, line 41 skipping to change at page 162, line 41
A legacy decryption-capable MUA that is unaware of this mechanism A legacy decryption-capable MUA that is unaware of this mechanism
will ignore the hp-legacy-display="1" parameter and instead render will ignore the hp-legacy-display="1" parameter and instead render
the body including the Legacy Display elements: the body including the Legacy Display elements:
Subject: Dinner plans Subject: Dinner plans
Let's meet at Rama's Roti Shop at 8pm and go to the park Let's meet at Rama's Roti Shop at 8pm and go to the park
from there. from there.
Appendix F. Document Considerations Appendix E. 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 This draft is built from markdown source, and its development is
tracked in a git repository (https://gitlab.com/dkg/lamps-header- tracked in a git repository (https://gitlab.com/dkg/lamps-header-
protection). protection).
You may also be interested in the latest editor's copy
(https://dkg.gitlab.io/lamps-header-protection/).
While minor editorial suggestions and nit-picks can be made as merge While minor editorial suggestions and nit-picks can be made as merge
requests (https://gitlab.com/dkg/lamps-header-protection), please requests (https://gitlab.com/dkg/lamps-header-protection), please
direct all substantive discussion to the LAMPS mailing list direct all substantive discussion to the LAMPS mailing list
(https://www.ietf.org/mailman/listinfo/spasm) at spasm@ietf.org. (https://www.ietf.org/mailman/listinfo/spasm) at spasm@ietf.org.
Appendix G. Document Changelog Appendix F. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]] [[ RFC Editor: This section is to be removed before publication ]]
* draft-ietf-lamps-header-protection-08
- MUST compose injected headers, MAY compose wrapped messages
- MUST parse both schemes
- cleanup and restructure document
* draft-ietf-lamps-header-protection-07
- move from legacy display MIME part to legacy display elements
within main body part
* draft-ietf-lamps-header-protection-06 * draft-ietf-lamps-header-protection-06
- document observed problems with legacy MUAs - document observed problems with legacy MUAs
- avoid duplicated outer Message-IDs in hcp_strong test vectors - avoid duplicated outer Message-IDs in hcp_strong test vectors
* draft-ietf-lamps-header-protection-05 * draft-ietf-lamps-header-protection-05
- fix multipart/signed wrapped test vectors - fix multipart/signed wrapped test vectors
skipping to change at page 172, line 50 skipping to change at page 164, line 18
* 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 definitions for Cryptographic Layer, Cryptographic
Payload, and Cryptographic Envelope (reference to Payload, and Cryptographic Envelope (reference to
[I-D.ietf-lamps-e2e-mail-guidance]) [DKG] [I-D.ietf-lamps-e2e-mail-guidance]) [DKG]
- Enhanced MITM Definition to include Machine- / Meddler-in-the- - Enhanced MITM Definition to include Machine- / Meddler-in-the-
middle [HB] middle [HB]
- Relaxed definition of Original message, which may not be of - Relaxed definition of Original message, which may not be of
type "message/rfc822" [HB] type "message/rfc822" [HB]
- Move "memory hole" option to the Appendix (on request by Chair - Move "memory hole" option to the Appendix (on request by Chair
skipping to change at page 173, line 28 skipping to change at page 164, line 45
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 H. Open Issues Appendix G. 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 D.1.1.1. Section 5.1. (Multipart Media Type).
* Test Vectors! We can point to the relevant test vector in the
main text by reference. We should also include in the test
vectors an encrypted message that references another message, so
we can observe the effect of the HCP on threading.
* Should Outer Message Header Section (as received) be preserved for
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.
* Enhance Introduction Section 1 and Problem Statement (Section 2).
* Decide on whether or not specification for more legacy HP * Decide on whether or not specification for more legacy HP
requirements should be added to this document (Section 3.1.2). requirements should be added to this document.
* Verify simple backward compatibility case (Receiving Side MIME-
Conformant) is working; once solution is stable and update
paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1
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 messages without
update Section 3.1 accordingly. header protection, and update receiving guidance accordingly.
* Improve definitions of Protection Levels and enhance list of
Protection Levels (Section 3.2, Section 4).
* Privacy Considerations Section 7 * Privacy Considerations Section 6
* Security Considerations Section 6 * Security Considerations Section 5
Authors' Addresses Authors' Addresses
Daniel Kahn Gillmor Daniel Kahn Gillmor
American Civil Liberties Union American Civil Liberties Union
125 Broad St. 125 Broad St.
New York, NY, 10004 New York, NY, 10004
United States of America United States of America
Email: dkg@fifthhorseman.net 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/
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. 281 change blocks. 
1261 lines changed or deleted 867 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/