]> 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 and Real-Time 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. Discussion Venues Discussion of this document takes place on the Structured Email Working Group mailing list (sml@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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 recommends security and trust mechanisms that should be applied when processing machine-readable content in email messages, both by senders and receivers.

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. This section is informative.

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 compatibility.

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.

Additional user interface options Structured mail processing may provide the receiving user with additional commands. Returning to the calendar example, many MUAs provide the user with additional commands to add something to a calendar.

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 then that".

Trust mechanisms Several implementations of structured email restrict processing to messages that are particularly trusted. That is to say, an incoming message may fall into 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 to differentiate between 2 and 3. It does not attempt to describe whether a trust-based mechanism is appopriate in a particular case.

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

• Processing the data offers no additional attack surface compared to displaying the HTML in which the structured data is embedded. This may often be the case for formal display.
• Only for MUAs that process calendar invitations/updates: The MUA would process a calendar invitation in the same message.
• The sender is trusted and the message contains a valid personal or domain signature. (This document does not describe any conditions for whether to trust senders.)
• The sender is trusted and the message contains a valid personal or domain DKIM signature (see ).
• The structured data is signed using JWS and the signer is trusted.
• The message is part of an ongoing thread with a trusted sender.
• The message's content indicate a connection with an older, trusted message. For example, if a calendar invitation was accepted, then updates or responses for the same event are connected with the original.

Structured data that requires or suggests automatic processing may benefit from additional precautions before acting on the message. Documents that specify such data types should discuss how recipients should decide whether to act.

Signatures Two signature schemes are relevant for structured data, namely DKIM (see ) and JWS (see ). Both connect particular message content to a signer, ie. a MUA can trust that the content comes from that source, but not whether that source is itself trustworthy. This document does not offer any advice on how to assess whether a particular sender/signer is trustworthy or not. For DKIM, the entire message is signed, as usual. For JWS, a part of the message may be signed, typically only the structured data. Open issue 1: Use detached content as defined in RFC7515 appendix F? That's nicely parsable, the signature is a plain extra, next to the JSON-LD. Open issue 2: Use bytewise comparison as described in , or the canonical format described in ? (Arnt's preliminary position: yes to detached for a plainer transition path from gmail++'s current format, no to 8785 since AFAICT the most common modifications made en route are to change URLs to some antivirus mitm.)

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 the data SHOULD be self-contained, such that the interaction will not need referenced resources from the web.

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 audriga GmbH This document specifies how a machine-readable variant of its content can be added to email messages. 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] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. 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. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. n.d. n.d.

Acknowledgements The authors wish to thank Ben Bucksch, Alexey Melnikov, Phillip Tao, Lisa Dusseault, Orie Steele, Daniel Kahn Gillmor, and others whose suggestions were made before this paragraph was started.

Note to self RFC Editor: Please remove this section. The charter has this to say about what this document should contain: "Recommendations for security and trust mechanisms that should be applied when processing machine-readable content in email messages" and "security and trust recommendations to prevent abuse of structured email". No more, no less.