]> audriga

happel@audriga.com https://www.audriga.com

ICANN

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

Applications sml 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.

Introduction Structured email, as described in , 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 considerations, or bring new urgency to existing issues. This document discusses issues related to trust and security of structured email, and provides advice in some cases.

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 when, and only when, they appear in all capitals, as shown here.

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. The same concerns often arise for other messages, of course.

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.

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.

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. Such automation could be a custom MUA feature or a future extension of the Sieve email filtering language (). A related example for abuse in automated processing is calendar spam ().

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.

Social engineering While the risks of social engineering are hardly new and the human-readable text in a message can in principle be used to persuade the human reader to do anything, structured data widens the variety of actions the human reader can easily perform. If there are more buttons to click, then there's also a greater variety of attacks. Put differently: A user who might not be able to follow the instructions in a long and involved text-based social engineering attack may be able to follow simple instructions such as "click this ten that".

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. It is RECOMMENDED to restrict trust to a simple "or", rather than e.g. an elaborate scoring mechanism that's difficult to understand for users.

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. While this is mentioned in and , 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. Some services differentiate between local mail and mail that arrived across the internet, and trust local mail. In particular, one author has seen that attachments sent by remote senders are distrusted ("warning! do you really want to download this?") while attachments from senders within the recipient's organization are assumed to be benevolent. OPEN ISSUE: Whether this should discuss combining sender trust with sender/domain signatures. Pro: A sender that has used DKIM may be assumed trustworthy if subsequent message also do it, less so if not. Contra: Isn't this what DMARC does, and best regulated only there?

Sender signatures Sender signatures such as PGP or S/MIME could potentially be used as a trust indicator. The authors aren't aware of any concrete examples of this in the past, perhaps because of limited deployment.

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.

Recipient-generated 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 requires 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.

Secrets and related messages A message may contain a secret or hard-to-guess identifier. A message may leverage another message's trust level by referencing an identifier from the other message. For example, a ticket sold by a concert venue may reference the payment transaction ID that's also mentioned in a message from the payment processor. If these IDs are difficult to guess and the receiver trusts the payment processor, then this gives some reason to trust that the ticket is bona fide and could safely be added to the user's ticket/wallet app. In another example, a message with a calendar update may reference an identifier from the original calendar entry. If this ID is hard to guess and the recipient acted on the message containing the original entry, then this gives some reason to trust that the change is bona fide. OPEN ISSUE: How to specify the secret. One possible solution: The leveraging message contains a specification of sender domain and optinal xpath query, and the MUA decides whether the sender is on its list. But I don't like having xpath, its interop is said to be poor and a malevolent sender could specify something easily guessed. For example, the messages I receive from a popular payment processor contain my name; an attacker could use an xpath query that results in my name. Another possible solution: The leveraging message specifies the sender of the leveraged message and the secret, and each MUA contains a hardcoded xpath query to find the ONLY kind of secret it trusts for that particular sender.

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.

Implementation guidelines

Processing structured data MUAs SHOULD consider structured data in incoming email messages only if either of these criteria hold:

• 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 these criteria is fulfilled, MUAs should fall back to alternative presentations (e.g., "text/html" or "text/plain"). Open issue 2: Really SHOULD? I (Arnt) don't see this guidance as clearly right. It doesn't match existing code well, and doesn't seem to be where we want to go.

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.

Implementation status RFC Editor: before publication please remove this section and the reference to . 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 . 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 , "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".

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

Security considerations Security considerations are a core subject of this document.

Privacy considerations Privacy considerations are a core subject of this document.

IANA Considerations This document has no IANA actions at this time.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK] This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature. [STANDARDS-TRACK] The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server. This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. n.d. n.d.

Acknowledgements The authors wish to thank Ben Bucksch, Alexey Melnikov, Phillip Tao and others whose suggestions were made before this paragraph was started.