Internet DRAFT - draft-happel-structured-email-trust
draft-happel-structured-email-trust
Network Working Group H.-J. Happel
Internet-Draft audriga GmbH
Intended status: Informational 23 October 2023
Expires: 25 April 2024
Structured Email: Trust and security considerations
draft-happel-structured-email-trust-00
Abstract
This document discusses trust and security considerations for
"structured email" ([I-D.happel-structured-email-00]) 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 25 April 2024.
Copyright Notice
Copyright (c) 2023 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 Expires 25 April 2024 [Page 1]
Internet-Draft Structured Email: Trust and security con October 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Types of security concerns . . . . . . . . . . . . . . . . . 3
3.1. Formal representation of data . . . . . . . . . . . . . . 3
3.2. Automated processing . . . . . . . . . . . . . . . . . . 3
3.3. External references . . . . . . . . . . . . . . . . . . . 3
4. Content encryption mechanisms . . . . . . . . . . . . . . . . 4
5. Trust mechanisms . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Trusted senders . . . . . . . . . . . . . . . . . . . . . 4
5.2. Sender signatures . . . . . . . . . . . . . . . . . . . . 4
5.3. Domain signatures . . . . . . . . . . . . . . . . . . . . 4
5.4. Transaction identifiers . . . . . . . . . . . . . . . . . 4
6. Categories of use cases . . . . . . . . . . . . . . . . . . . 5
7. Implementation guidelines . . . . . . . . . . . . . . . . . . 5
7.1. Processing structured data . . . . . . . . . . . . . . . 5
7.2. Inlining data . . . . . . . . . . . . . . . . . . . . . . 5
8. Implementation status . . . . . . . . . . . . . . . . . . . . 5
8.1. Structured Email plugin for Roundcube Webmail . . . . . . 6
9. Security considerations . . . . . . . . . . . . . . . . . . . 6
10. Privacy considerations . . . . . . . . . . . . . . . . . . . 6
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
12. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Structured email aims to make the content of email messages machine-
readable, such that algorithms can help users deal more efficiently
with their email.
Accordingly, special considerations with respect to security and
trust of structured data in emails should apply for such algorithms.
2. Conventions Used in This Document
The terms "message" and "email message" refer to "electronic mail
messages" or "emails" as specified in [RFC5322]. The term "Message
User Agent" (MUA) denotes an email client application as per
[RFC5598].
The terms "machine-readable data" and "structured data" are used in
contrast to "human-readable" messages and denote information
expressed "in a structured format (..) which can be consumed by
another program using consistent processing logic" [MachineReadable].
Happel Expires 25 April 2024 [Page 2]
Internet-Draft Structured Email: Trust and security con October 2023
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.
3. Types of security concerns
This section discusses security and privacy concerns that may be
raised when introducing structured data into email messages.
3.1. Formal representation of data
Structured email aims to provide a machine-readable version of email
content. Hence, the machine-readable information typically won't go
beyond what is communicated in the human-readable part of email
messages.
Accordingly, the major difference is the formal nature of the data,
which makes it easier to extract and process. Certain forms of
formal data are however already common today, such as (flight)
reservation data encoded using barcode or the PKPASS format.
3.2. Automated processing
Structured data in email messages might users want to create certain
automated processing chains. For example, a user might want flight
reservations to be automatically added to a travel itinerary
application.
Such automation could be a custom feature of their MUA or a future
extension of the Sieve email filtering language [RFC5228]. A related
example for abuse in automated processing is calendar spam
([CalSpam]).
3.3. External references
Emails with a text/html body part ("HTML emails"), may contain image
resources that link to web servers. Such links can be used for
tracking user interaction with their MUA.
Similar concerns would 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.
Happel Expires 25 April 2024 [Page 3]
Internet-Draft Structured Email: Trust and security con October 2023
In addition, RDF structured data might be impartial by design and
include mere references for additional data. Using a "follow your
nose" approach, tools can try following URL references to obtain
further structured data concerning a resource.
For example, a piece of structured data about a news article could
opt to 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. Content encryption mechanisms
5. Trust mechanisms
5.1. Trusted senders
For the case of displaying remote images embedded in HTML emails,
MUAs often allow users to manually choose if they trust a certain
sender.
In addition, such trusted senders may be added to the MUAs address
book or a special list therein.
Besides mentions in related use cases ([RFC6132]/[RFC6134]) this
mechanism is currently not standardized.
5.2. Sender signatures
5.3. Domain signatures
5.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 puts
burden on the recipient to discern if a message is legitimate 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.
Happel Expires 25 April 2024 [Page 4]
Internet-Draft Structured Email: Trust and security con October 2023
Open issues
* Message id?
6. 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.
7. Implementation guidelines
7.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).
Open isues
* Github
7.2. Inlining data
Strucutured data included in an email message should be self-
contained. This means that a MUA should be able to provide
meaningful user interaction also without loading additional
referenced resources from the web.
Open issues
* Github
8. 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
Happel Expires 25 April 2024 [Page 5]
Internet-Draft Structured Email: Trust and security con October 2023
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".
8.1. Structured Email plugin for Roundcube Webmail
The plugin will currently use the "trusted sender" feature of
Roundcube to determine if structured data should be processed.
9. Security considerations
Security considerations are core subject of this document itself.
10. Privacy considerations
Privacy considerations are core subject of this document itself.
11. IANA Considerations
This document has no IANA actions at this time.
12. Informative References
[CalSpam] The Calendaring and Scheduling Consortium (“CalConnect”),
"Calendar operator practices — Guidelines to protect
against calendar abuse (CC/R 18003:2019)",
<https://standards.calconnect.org/csd/cc-18003.html>.
[MachineReadable]
NIST, "NIST IR 7511 Rev. 4",
<https://csrc.nist.gov/glossary/term/Machine_Readable>.
[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/info/rfc2119>.
Happel Expires 25 April 2024 [Page 6]
Internet-Draft Structured Email: Trust and security con October 2023
[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/info/rfc5228>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC6132] George, R. and B. Leiba, "Sieve Notification Using
Presence Information", RFC 6132, DOI 10.17487/RFC6132,
July 2011, <https://www.rfc-editor.org/info/rfc6132>.
[RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally
Stored Lists", RFC 6134, DOI 10.17487/RFC6134, July 2011,
<https://www.rfc-editor.org/info/rfc6134>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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/info/rfc8174>.
Author's Address
Hans-Joerg Happel
audriga GmbH
Email: happel@audriga.com
URI: https://www.audriga.com
Happel Expires 25 April 2024 [Page 7]
