Trust and security considerations for Structured Email
draft-happel-structured-email-trust-01

sml                                                         H.-J. Happel
Internet-Draft                                                   audriga
Intended status: Standards Track                          A. Gulbrandsen
Expires: 9 January 2025                                            ICANN
                                                             8 July 2024

         Trust and security considerations for Structured Email
                 draft-happel-structured-email-trust-01

Abstract

   This document discusses trust and security considerations for
   structured email and provides recommendations for message user agents
   on how to deal with structured data in email messages.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 9 January 2025.

Copyright Notice

   Copyright (c) 2024 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
   and restrictions with respect to this document.  Code Components
   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.

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 1]
Internet-Draft                  SML Trust                      July 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Types of security concerns  . . . . . . . . . . . . . . . . .   3
     3.1.  Spam/virus filters  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Formal display of data  . . . . . . . . . . . . . . . . .   3
     3.3.  Automated processing  . . . . . . . . . . . . . . . . . .   3
     3.4.  External references . . . . . . . . . . . . . . . . . . .   4
   4.  Trust mechanisms  . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Trusted senders . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Sender signatures . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Domain signatures . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Transaction identifiers . . . . . . . . . . . . . . . . .   5
   5.  Categories of use cases . . . . . . . . . . . . . . . . . . .   5
   6.  Implementation guidelines . . . . . . . . . . . . . . . . . .   5
     6.1.  Processing structured data  . . . . . . . . . . . . . . .   6
     6.2.  Inlining data . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Implementation status . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Structured Email plugin for Roundcube Webmail . . . . . .   7
   8.  Security considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Structured email, as described in [I-D.sml-structured-email], makes
   the content of some email messages machine-readable, such that user
   agents can provide higher-level functions than displaying/replying,
   for example "add this to calendar".

   Naturally, new functions bring new trust and security consideratons.
   This document discusses issues related to trust and security of
   structured email, and provides advice in some cases.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 2]
Internet-Draft                  SML Trust                      July 2024

3.  Types of security concerns

   This section gives an overview of the various types of security and
   privacy concerns that arise when email messages contain structured
   data.

3.1.  Spam/virus filters

   Structured email increases the syntactical and semantic complexity of
   email messages.  If a spam/virus filter parses structured email in
   order to block malevolent messages, the filter's parser will
   necessarily differ from that of the MUA that will finally act on the
   structured data, creating a risk of misclassification.

   These risks are elevated when a structured data format has complex
   syntax, syntax that offers several optional or alternative ways to
   express the same substance, and of course by parsers that deviate
   from the specification for better bug compatibiloty.

3.2.  Formal display of data

   A common example is displaying a received calendar invitation using
   dates/times in the recipient's timezone, in a fixed format.

   Formal display introduces additional possibilities of discrepancy
   between the different representations.  For example, a single message
   might contains a multipart/alternative containing a text/plain
   description of a flight itinerary, a text/html description of the
   same itinerary, and a structured representation.  All three may be
   different, leading to confusion (and in this example, perhaps to
   missing a flight).

   Unintentional discrepancy is a risk for senders; some recipients may
   be misinformed.

   If a message is sent to a group and there is a discrepancy, different
   members of the group may see it differently.

   If a particular MUA displays the formal representation within the
   message, a malevolent sender could try to mimic the visual
   representation using HTML with CSS, but with misleading content.

3.3.  Automated processing

   Automated processing covers actions that are taken as soon as the
   message arrives rather than when a human user reads the message.  For
   example, a user might want flight reservations to be automatically
   added to a travel itinerary application and/or a calendar.

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 3]
Internet-Draft                  SML Trust                      July 2024

   Such automation could be a custom MUA feature or a future extension
   of the Sieve email filtering language ([RFC5228]).  A related example
   for abuse in automated processing is calendar spam ([CalSpam]).

3.4.  External references

   Email messages with a text/html body part ("HTML email messages") may
   contain image resources that link to web servers.  Such links can be
   used for tracking user interaction with the message.

   Similar concerns apply to structured data types which include image
   references, such as the cover image of a music album or the teaser
   image of a news article.

   RDF structured data can be partial by design and include references
   to additional data.  Using a "follow your nose" approach, tools can
   follow URL references to obtain further structured data concerning a
   resource.  For example, a piece of structured data about an article
   could reference the article's authors only by URL.  For a meaningful
   processing of author information, one might try to obtain further
   data using that URL.

4.  Trust mechanisms

   Several implementations of structured email restrict processing to
   messages that are particularly trusted.  That is to say, an incoming
   message is in one of these three categories:

   1.  Spam.  Structured data is not processed.

   2.  Ordinary.  Structured data is not processed.

   3.  Trusted.  Structured data is processed.

   This section gives an overview of the trust mechanisms used at the
   time of writing.

   It does not attempt to describe whether a trust-based mechanism is
   appopriate in a particular case.

4.1.  Trusted senders

   For the case of displaying remote images embedded in HTML email
   messages, MUAs often allow users to manually choose if they trust a
   certain sender.

   Sometimes, addresses in the MUA's address book are considered
   trusted, or in a special list in the address book.

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 4]
Internet-Draft                  SML Trust                      July 2024

   Besides mentions in related use cases ([@RFC6132]/[@RFC6134]) this
   mechanism is currently not standardized.

   Several services manage trust centrally: trusted senders are trusted
   by the mail service rather than by the individual users.

4.2.  Sender signatures

4.3.  Domain signatures

   DKIM defines a signature on sender domain that may be used to verify
   that a message was sent by the same sender as an earlier message.

   Some mail hosts restrict structured processing to messages with DKIM
   signatures, or to a set of senders who are identified by their DKIM
   signatures.

4.4.  Transaction identifiers

   Part of the simplicity of email is the fact that just the email
   address is required to reach out to a recipient.  This however
   required the the recipient to discern whether a message is desirable
   or abusive.

   Recipient-generated transaction identifiers aim to pass a certain
   secret to the sender, which helps to prove legitimacy.  One such
   approach are one-time email aliases, which are generated for a single
   transaction or series of transactions.

   Structured email by itself might also help define special types of
   structured data that could help to manage and communicate transaction
   identifiers more easily.

   Open issue 1: Propose a header field with an opaque cookie like
   thread-id, to tie a message to older messages?

5.  Categories of use cases

   Certain types of structured data might need to be kept more secure
   than others.  For instance, the structured data representation of a
   music album shared by a friend would not contain major personal
   information, while e.g., medical records or financial statements
   certainly would.

6.  Implementation guidelines

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 5]
Internet-Draft                  SML Trust                      July 2024

6.1.  Processing structured data

   MUAs SHOULD consider structured data in incoming email messages only
   if:

   *  The sender is trusted (e.g., part of the user's address book) and
      the messsage either contains a valid personal or domain signature

   *  The message is part of an ongoing thread with a trusted sender

   If none of those criteria is fulfilled, MUAs should fallback to
   alternative presentations (e.g., "text/html" or "text/plain" of such
   message).

6.2.  Inlining data

   Structured data included in an email message should be self-contained
   in order to avoid privacy problems.  This implies that if an MUA is
   able to provide meaningful user interaction (rather than mere
   display), then it should do that without loading additional
   referenced resources from the web.

7.  Implementation status

   RFC Editor: before publication please remove this section and the
   reference to [@RFC7942]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [@RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [@RFC7942], "this will allow reviewers and working
   groups to assign due consideration to documents that have the benefit
   of running code, which may serve as evidence of valuable
   experimentation and feedback that have made the implemented protocols
   more mature.  It is up to the individual working groups to use this
   information as they see fit".

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 6]
Internet-Draft                  SML Trust                      July 2024

7.1.  Structured Email plugin for Roundcube Webmail

   The plugin currently uses the "trusted sender" feature of Roundcube
   to determine if structured data should be processed.

8.  Security considerations

   Security considerations are a core subject of this document.

9.  Privacy considerations

   Privacy considerations are a core subject of this document.

10.  IANA Considerations

   This document has no IANA actions at this time.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2.  Informative References

   [I-D.sml-structured-email]
              "*** BROKEN REFERENCE ***".

   [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
              January 2008, <https://www.rfc-editor.org/rfc/rfc5228>.

   [CalSpam]  "Calendar operator practices — Guidelines to protect
              against calendar abuse", n.d.,
              <https://standards.calconnect.org/csd/cc-18003.html>.

   [MachineReadable]
              "NIST IR 7511 Rev 4", n.d.,
              <https://csrc.nist.gov/glossary/term/Machine_Readable>.

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 7]
Internet-Draft                  SML Trust                      July 2024

Appendix A.  Acknowledgements

   The authors wish to thank [your name here, please]

Authors' Addresses

   Hans-Joerg Happel
   audriga
   Email: happel@audriga.com
   URI:   https://www.audriga.com

   Arnt Gulbrandsen
   ICANN
   6 Rond Point Schumann, Bd. 1
   1040 Brussels
   Belgium
   Email: arnt@gulbrandsen.priv.no
   URI:   https://icann.org/ua

Happel & Gulbrandsen     Expires 9 January 2025                 [Page 8]