--- 1/draft-ietf-lamps-e2e-mail-guidance-01.txt 2022-01-25 13:13:09.581235678 -0800 +++ 2/draft-ietf-lamps-e2e-mail-guidance-02.txt 2022-01-25 13:13:09.633236975 -0800 @@ -1,18 +1,18 @@ lamps D.K. Gillmor, Ed. Internet-Draft ACLU -Intended status: Informational 24 January 2022 -Expires: 28 July 2022 +Intended status: Informational 25 January 2022 +Expires: 29 July 2022 Guidance on End-to-End E-mail Security - draft-ietf-lamps-e2e-mail-guidance-01 + draft-ietf-lamps-e2e-mail-guidance-02 Abstract End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 July 2022. + This Internet-Draft will expire on 29 July 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -48,82 +48,84 @@ extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4 + 1.2.2. User-Facing Headers . . . . . . . . . . . . . . . . . 5 2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 5 - 2.3. Warning About Failure vs. Announcing Success . . . . . . 6 - 3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 7 - 4. Cryptographic MIME Message Structure . . . . . . . . . . . . 7 - 4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 7 + 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 6 + 2.3. Warning About Failure vs. Announcing Success . . . . . . 7 + 3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 8 + 4. Cryptographic MIME Message Structure . . . . . . . . . . . . 8 + 4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 8 4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 8 4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 9 - 4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 9 - 4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 10 - 4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 10 - 4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 10 - 4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 10 + 4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 10 + 4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 11 + 4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 11 + 4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 11 + 4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 11 4.5. Errant Crytptographic Layers . . . . . . . . . . . . . . 11 - 4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 11 - 4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 11 - 5. Message Composition . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. Message Composition Algorithm . . . . . . . . . . . . . . 12 - 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 13 - 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 13 - 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 14 + 4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 12 + 4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 12 + 5. Message Composition . . . . . . . . . . . . . . . . . . . . . 13 + 5.1. Message Composition Algorithm . . . . . . . . . . . . . . 13 + 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 14 + 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 14 + 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 15 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15 - 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 15 - 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 15 - 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 15 - 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 17 + 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 16 + 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 16 + 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 16 + 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 18 6.3. Forwarded Messages with Cryptographic Protection . . . . 18 - 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 18 - 7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 19 - 7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 19 - 7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 19 + 7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 20 + 7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 20 + 7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21 - 8. Certificate Management . . . . . . . . . . . . . . . . . . . 22 - 8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 22 - 8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 22 - 8.1.2. Certificate Directories . . . . . . . . . . . . . . . 22 - 8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 22 - 8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 23 - 8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 23 - 8.2.1. Getting a Certificate for the User . . . . . . . . . 23 + 8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 23 + 8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 23 + 8.1.2. Certificate Directories . . . . . . . . . . . . . . . 23 + 8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 23 + 8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 24 + 8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 24 + 8.2.1. Getting a Certificate for the User . . . . . . . . . 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 - 9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 25 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 26 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 - 13.2. Informative References . . . . . . . . . . . . . . . . . 26 - Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 - Appendix B. Document Considerations . . . . . . . . . . . . . . 28 - B.1. Document History . . . . . . . . . . . . . . . . . . . . 28 - B.1.1. Substantive changes from draft-ietf-...-00 to - draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 28 - B.1.2. Substantive changes from draft-dkg-...-01 to - draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 28 - B.1.3. Substantive changes from draft-dkg-...-00 to - draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 28 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 + 13.2. Informative References . . . . . . . . . . . . . . . . . 27 + Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 28 + Appendix B. Document Considerations . . . . . . . . . . . . . . 29 + B.1. Document History . . . . . . . . . . . . . . . . . . . . 29 + B.1.1. Substantive changes from draft-ietf-...-01 to + draft-ietf-...-02 . . . . . . . . . . . . . . . . . . 29 + B.1.2. Substantive changes from draft-ietf-...-00 to + draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 29 + B.1.3. Substantive changes from draft-dkg-...-01 to + draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 29 + B.1.4. Substantive changes from draft-dkg-...-00 to + draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 29 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME ([RFC3156]) cryptographic standards can provide integrity, authentication and confidentiality to MIME ([RFC4289]) e-mail messages. However, there are many ways that a receiving mail user agent can misinterpret or accidentally break these security guarantees (e.g., @@ -159,20 +161,22 @@ * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic Payload_, and _Errant Cryptographic Layer_ are defined in Section 4 * A _well-formed_ e-mail message with cryptographic protection has both a _Cryptographic Envelope_ and a _Cryptographic Payload_. * _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 rendered to the user as the message itself (not "as an attachment). See Section 7.1. 1.2.1. Structural Headers A message header whose name begins with Content- is referred to in this document as a "structural" header. These headers indicate something about the specific MIME part they @@ -175,27 +179,56 @@ A message header whose name begins with Content- is referred to in this document as a "structural" header. These headers indicate something about the specific MIME part they are attached to, and cannot be transferred or copied to other parts without endangering the readability of the message. This includes (but is not limited to): * Content-Type + * Content-Transfer-Encoding * Content-Disposition FIXME: are there any non-Content-* headers we should consider as 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 Any MUA that enables its user to transition from unprotected messages to messages with end-to-end cryptographic protection needs to consider how the user understands this transition. That said, the primary goal of the user of an MUA is communication -- so interface elements that get in the way of communication should be avoided where possible. Furthermore, it is likely is that the user will continue to encounter @@ -884,38 +915,41 @@ 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 "Main Body Part". When rendering a message, one of the primary jobs of the recieving MUA is identifying which part (or parts) is the Main Body Part. 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. text/plain or text/html) and is not Content-Disposition: attachment. + MIME tree traversal follows the first child of every multipart node, with the exception of multipart/alternative. When traversing a multipart/alternative node, all children should be scanned, with 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 - mechanism to prefer a particular MIME type within multipart/ - alternative instead of the last renderable child. For example, a - user may explicitly prefer a text/plain alternative part over text/ - html. + is capable of rendering directly. + + A MUA MAY offer the user a mechanism to prefer a particular MIME type + within multipart/alternative instead of the last renderable child. + 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 of the receiving MUA, the composing MUA SHOULD consider that multiple parts might be rendered as the Main Body Part when the message is ultimately viewed. When composing a message, an originating MUA operating on behalf of 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. + Tooling that automatically generates e-mail messages should also have a reasonable estimate of which part (or parts) are the "main" parts, as they can be programmatically identified by the message author. For a filtering program that attempts to transform an outbound message without any special knowledge about which parts are Main Body Parts, it can identify the likely parts by following the same routine as a receiving MUA. 7.2. Attachments @@ -1166,21 +1199,22 @@ * aggregated cryptographic status of threads/conversations ? * Draft messages * copies to the Sent folder 10. IANA Considerations 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 This entire document addresses security considerations about end-to- end cryptographic protections for e-mail messages. 12. Acknowledgements The set of constructs and recommendations in this document are derived from discussions with many different implementers, including @@ -1288,35 +1322,39 @@ (https://dkg.gitlab.io/e2e-mail-guidance/). Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor. Please direct all significant commentary to the public IETF LAMPS mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/ spasm). 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 * Updated document considerations section, including reference to 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 * moved Document History and Document Considerations sections to end 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 * clarify extendedKeyUsage and keyUsage algorithm-specific details * initial section on certificate management * added more TODO items Author's Address