draft-ietf-lamps-e2e-mail-guidance-01.txt   draft-ietf-lamps-e2e-mail-guidance-02.txt 
lamps D.K. Gillmor, Ed. lamps D.K. Gillmor, Ed.
Internet-Draft ACLU Internet-Draft ACLU
Intended status: Informational 24 January 2022 Intended status: Informational 25 January 2022
Expires: 28 July 2022 Expires: 29 July 2022
Guidance on End-to-End E-mail Security Guidance on End-to-End E-mail Security
draft-ietf-lamps-e2e-mail-guidance-01 draft-ietf-lamps-e2e-mail-guidance-02
Abstract Abstract
End-to-end cryptographic protections for e-mail messages can provide End-to-end cryptographic protections for e-mail messages can provide
useful security. However, the standards for providing cryptographic useful security. However, the standards for providing cryptographic
protection are extremely flexible. That flexibility can trap users protection are extremely flexible. That flexibility can trap users
and cause surprising failures. This document offers guidance for and cause surprising failures. This document offers guidance for
mail user agent implementers that need to compose or interpret e-mail mail user agent implementers that need to compose or interpret e-mail
messages with end-to-end cryptographic protection. It provides a messages with end-to-end cryptographic protection. It provides a
useful set of vocabulary as well as suggestions to avoid common useful set of vocabulary as well as suggestions to avoid common
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 28 July 2022. This Internet-Draft will expire on 29 July 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4 1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4
1.2.2. User-Facing Headers . . . . . . . . . . . . . . . . . 5
2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 5 2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 6
2.3. Warning About Failure vs. Announcing Success . . . . . . 6 2.3. Warning About Failure vs. Announcing Success . . . . . . 7
3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 7 3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 8
4. Cryptographic MIME Message Structure . . . . . . . . . . . . 7 4. Cryptographic MIME Message Structure . . . . . . . . . . . . 8
4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 7 4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 8
4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 8 4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 8
4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 9 4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 9
4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 9 4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 10
4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 10 4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 11
4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 10 4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 11
4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 10 4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 11
4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 10 4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 11
4.5. Errant Crytptographic Layers . . . . . . . . . . . . . . 11 4.5. Errant Crytptographic Layers . . . . . . . . . . . . . . 11
4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 11 4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 12
4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 11 4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 12
5. Message Composition . . . . . . . . . . . . . . . . . . . . . 12 5. Message Composition . . . . . . . . . . . . . . . . . . . . . 13
5.1. Message Composition Algorithm . . . . . . . . . . . . . . 12 5.1. Message Composition Algorithm . . . . . . . . . . . . . . 13
5.2. Encryption Outside, Signature Inside . . . . . . . . . . 13 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 14
5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 13 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 14
5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 14 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 15
6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15
6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 15 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 16
6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 15 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 16
6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 15 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 16
6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 17 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 18
6.3. Forwarded Messages with Cryptographic Protection . . . . 18 6.3. Forwarded Messages with Cryptographic Protection . . . . 18
6.4. Signature failures . . . . . . . . . . . . . . . . . . . 18 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 19
7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 19 7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 20
7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 19 7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 20
7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21 7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21
8. Certificate Management . . . . . . . . . . . . . . . . . . . 22 8. Certificate Management . . . . . . . . . . . . . . . . . . . 22
8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 22 8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 23
8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 22 8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 23
8.1.2. Certificate Directories . . . . . . . . . . . . . . . 22 8.1.2. Certificate Directories . . . . . . . . . . . . . . . 23
8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 22 8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 23
8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 23 8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 24
8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 23 8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 24
8.2.1. Getting a Certificate for the User . . . . . . . . . 23 8.2.1. Getting a Certificate for the User . . . . . . . . . 24
8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 24 8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 24
8.2.3. Shipping Certificates in Outbound Messages . . . . . 24 8.2.3. Shipping Certificates in Outbound Messages . . . . . 25
8.3. Certificate Authorities . . . . . . . . . . . . . . . . . 25 8.3. Certificate Authorities . . . . . . . . . . . . . . . . . 25
9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 25 9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 26 13.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Document Considerations . . . . . . . . . . . . . . 28 Appendix B. Document Considerations . . . . . . . . . . . . . . 29
B.1. Document History . . . . . . . . . . . . . . . . . . . . 28 B.1. Document History . . . . . . . . . . . . . . . . . . . . 29
B.1.1. Substantive changes from draft-ietf-...-00 to B.1.1. Substantive changes from draft-ietf-...-01 to
draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 28 draft-ietf-...-02 . . . . . . . . . . . . . . . . . . 29
B.1.2. Substantive changes from draft-dkg-...-01 to B.1.2. Substantive changes from draft-ietf-...-00 to
draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 28 draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 29
B.1.3. Substantive changes from draft-dkg-...-00 to B.1.3. Substantive changes from draft-dkg-...-01 to
draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 28 draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 B.1.4. Substantive changes from draft-dkg-...-00 to
draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME
([RFC3156]) cryptographic standards can provide integrity, ([RFC3156]) cryptographic standards can provide integrity,
authentication and confidentiality to MIME ([RFC4289]) e-mail authentication and confidentiality to MIME ([RFC4289]) e-mail
messages. messages.
However, there are many ways that a receiving mail user agent can However, there are many ways that a receiving mail user agent can
misinterpret or accidentally break these security guarantees (e.g., misinterpret or accidentally break these security guarantees (e.g.,
skipping to change at page 4, line 37 skipping to change at page 4, line 37
* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic
Payload_, and _Errant Cryptographic Layer_ are defined in Payload_, and _Errant Cryptographic Layer_ are defined in
Section 4 Section 4
* A _well-formed_ e-mail message with cryptographic protection has * A _well-formed_ e-mail message with cryptographic protection has
both a _Cryptographic Envelope_ and a _Cryptographic Payload_. both a _Cryptographic Envelope_ and a _Cryptographic Payload_.
* _Structural Headers_ are documented in Section 1.2.1. * _Structural Headers_ are documented in Section 1.2.1.
* _User-Facing Headers_ are documented in Section 1.2.2.
* _Main Body Part_ is the part (or parts) that are typically * _Main Body Part_ is the part (or parts) that are typically
rendered to the user as the message itself (not "as an rendered to the user as the message itself (not "as an
attachment). See Section 7.1. attachment). See Section 7.1.
1.2.1. Structural Headers 1.2.1. Structural Headers
A message header whose name begins with Content- is referred to in A message header whose name begins with Content- is referred to in
this document as a "structural" header. this document as a "structural" header.
These headers indicate something about the specific MIME part they These headers indicate something about the specific MIME part they
skipping to change at page 5, line 4 skipping to change at page 5, line 6
A message header whose name begins with Content- is referred to in A message header whose name begins with Content- is referred to in
this document as a "structural" header. this document as a "structural" header.
These headers indicate something about the specific MIME part they These headers indicate something about the specific MIME part they
are attached to, and cannot be transferred or copied to other parts are attached to, and cannot be transferred or copied to other parts
without endangering the readability of the message. without endangering the readability of the message.
This includes (but is not limited to): This includes (but is not limited to):
* Content-Type * Content-Type
* Content-Transfer-Encoding * Content-Transfer-Encoding
* Content-Disposition * Content-Disposition
FIXME: are there any non-Content-* headers we should consider as FIXME: are there any non-Content-* headers we should consider as
structural? structural?
1.2.2. User-Facing Headers
Of all the headers that an e-mail message may contain, only a handful
are typically presented directly to the user. The user-facing
headers are:
* Subject
* From
* To
* Cc
* Date
* Reply-To
* Followup-To
The above is a complete list. No other headers are considered "user-
facing".
Other headers may affect the visible rendering of the message (e.g.,
References and In-Reply-To may affect the placement of a message in a
threaded discussion), but they are not directly displayed to the user
and so are not considered "user-facing".
2. Usability 2. Usability
Any MUA that enables its user to transition from unprotected messages Any MUA that enables its user to transition from unprotected messages
to messages with end-to-end cryptographic protection needs to to messages with end-to-end cryptographic protection needs to
consider how the user understands this transition. That said, the consider how the user understands this transition. That said, the
primary goal of the user of an MUA is communication -- so interface primary goal of the user of an MUA is communication -- so interface
elements that get in the way of communication should be avoided where elements that get in the way of communication should be avoided where
possible. possible.
Furthermore, it is likely is that the user will continue to encounter Furthermore, it is likely is that the user will continue to encounter
skipping to change at page 19, line 50 skipping to change at page 20, line 33
While the message itself may be constructed of several distinct MIME While the message itself may be constructed of several distinct MIME
parts in a tree, but the part that is rendered to the user is the parts in a tree, but the part that is rendered to the user is the
"Main Body Part". "Main Body Part".
When rendering a message, one of the primary jobs of the recieving When rendering a message, one of the primary jobs of the recieving
MUA is identifying which part (or parts) is the Main Body Part. MUA is identifying which part (or parts) is the Main Body Part.
Typically, this is found by traversing the MIME tree of the message Typically, this is found by traversing the MIME tree of the message
looking for a leaf node that has a primary content type of text (e.g. looking for a leaf node that has a primary content type of text (e.g.
text/plain or text/html) and is not Content-Disposition: attachment. text/plain or text/html) and is not Content-Disposition: attachment.
MIME tree traversal follows the first child of every multipart node, MIME tree traversal follows the first child of every multipart node,
with the exception of multipart/alternative. When traversing a with the exception of multipart/alternative. When traversing a
multipart/alternative node, all children should be scanned, with multipart/alternative node, all children should be scanned, with
preference given to the last child node with a MIME type that the MUA preference given to the last child node with a MIME type that the MUA
is capable of rendering directly. A MUA MAY offer the user a is capable of rendering directly.
mechanism to prefer a particular MIME type within multipart/
alternative instead of the last renderable child. For example, a A MUA MAY offer the user a mechanism to prefer a particular MIME type
user may explicitly prefer a text/plain alternative part over text/ within multipart/alternative instead of the last renderable child.
html. For example, a user may explicitly prefer a text/plain alternative
part over text/html.
Note that due to uncertainty about the capabilities and configuration Note that due to uncertainty about the capabilities and configuration
of the receiving MUA, the composing MUA SHOULD consider that multiple of the receiving MUA, the composing MUA SHOULD consider that multiple
parts might be rendered as the Main Body Part when the message is parts might be rendered as the Main Body Part when the message is
ultimately viewed. ultimately viewed.
When composing a message, an originating MUA operating on behalf of When composing a message, an originating MUA operating on behalf of
an active user can identify which part (or parts) are the "main" an active user can identify which part (or parts) are the "main"
parts: these are the parts the MUA generates from the user's editor. parts: these are the parts the MUA generates from the user's editor.
Tooling that automatically generates e-mail messages should also have Tooling that automatically generates e-mail messages should also have
a reasonable estimate of which part (or parts) are the "main" parts, a reasonable estimate of which part (or parts) are the "main" parts,
as they can be programmatically identified by the message author. as they can be programmatically identified by the message author.
For a filtering program that attempts to transform an outbound For a filtering program that attempts to transform an outbound
message without any special knowledge about which parts are Main Body message without any special knowledge about which parts are Main Body
Parts, it can identify the likely parts by following the same routine Parts, it can identify the likely parts by following the same routine
as a receiving MUA. as a receiving MUA.
7.2. Attachments 7.2. Attachments
skipping to change at page 25, line 48 skipping to change at page 26, line 38
* aggregated cryptographic status of threads/conversations ? * aggregated cryptographic status of threads/conversations ?
* Draft messages * Draft messages
* copies to the Sent folder * copies to the Sent folder
10. IANA Considerations 10. IANA Considerations
MAYBE: provide an indicator in the IANA header registry for which MAYBE: provide an indicator in the IANA header registry for which
headers are "structural" ? This is probably unnecessary. headers are "structural" and which are "user-facing"? This is
probably unnecessary.
11. Security Considerations 11. Security Considerations
This entire document addresses security considerations about end-to- This entire document addresses security considerations about end-to-
end cryptographic protections for e-mail messages. end cryptographic protections for e-mail messages.
12. Acknowledgements 12. Acknowledgements
The set of constructs and recommendations in this document are The set of constructs and recommendations in this document are
derived from discussions with many different implementers, including derived from discussions with many different implementers, including
skipping to change at page 28, line 28 skipping to change at page 29, line 26
(https://dkg.gitlab.io/e2e-mail-guidance/). (https://dkg.gitlab.io/e2e-mail-guidance/).
Minor editorial changes can be suggested via merge requests at Minor editorial changes can be suggested via merge requests at
https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor. https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor.
Please direct all significant commentary to the public IETF LAMPS Please direct all significant commentary to the public IETF LAMPS
mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/ mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/
spasm). spasm).
B.1. Document History B.1. Document History
B.1.1. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01 B.1.1. Substantive changes from draft-ietf-...-01 to draft-ietf-...-02
* Added definition of "user-facing" headers
B.1.2. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01
* Added section about distinguishing Main Body Parts and Attachments * Added section about distinguishing Main Body Parts and Attachments
* Updated document considerations section, including reference to * Updated document considerations section, including reference to
auto-built editor's copy auto-built editor's copy
B.1.2. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00 B.1.3. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00
* WG adopted draft * WG adopted draft
* moved Document History and Document Considerations sections to end * moved Document History and Document Considerations sections to end
of appendix, to avoid section renumbering when removed of appendix, to avoid section renumbering when removed
B.1.3. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01 B.1.4. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01
* consideration of success/failure indicators for usability * consideration of success/failure indicators for usability
* clarify extendedKeyUsage and keyUsage algorithm-specific details * clarify extendedKeyUsage and keyUsage algorithm-specific details
* initial section on certificate management * initial section on certificate management
* added more TODO items * added more TODO items
Author's Address Author's Address
 End of changes. 24 change blocks. 
64 lines changed or deleted 105 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/