Session Date/Time: 10 Jan 2025 17:00

SML

Summary

The SML Working Group held an interim meeting primarily to discuss the draft-sml-trust-security-considerations document. Key discussions revolved around the document's descriptive approach, various security concerns associated with structured email, mechanisms for establishing trust, and the role of encryption. A general sense of the meeting supported the current descriptive approach while emphasizing the need to include existing practices and their caveats, along with exploring more nuanced trust mechanisms and the role of encryption. The chairs outlined next steps for the draft and the working group's future meetings.

Key Discussion Points

Chair Slides & Logistics
- The meeting was recorded and covered by the IETF Note Well.
- A note taker was established for the session.
draft-sml-trust-security-considerations Discussion
- Document Approach: The current draft takes a descriptive approach, detailing how code handles similar issues today (e.g., calendar invitations, Gmail/Apple handling of tickets). This was contrasted with a prescriptive approach. A sense of those present indicated support for the descriptive approach, as it acknowledges current practices.
- Security Concerns for Automatic Processing:
  - Structured email, especially with automatic processing, acts as a "virtual machine" similar to a web browser for JavaScript, introducing similar exploitation risks. Simple display has fewer such issues.
  - Divergence between different parsers (e.g., spam filter vs. user agent) for structured data can create security issues.
  - Different recipients may see different representations of the same message (e.g., different times for a flight), which is a known issue (e.g., with calendar invitations) but still a concern.
  - Data leaks via external references in structured data were noted as analogous to image leaks.
  - Phishing/Deception: Participants noted that structured data could create new varieties of phishing attacks by enabling more appealing presentations that deceive users into performing actions. The draft should acknowledge these new attack vectors.
- Automatic Processing Risks & User Control:
  - Automatic processing (e.g., adding calendar invitations directly) is desirable but adds risk, turning the user agent into a "virtual machine" for the content.
  - A sense of the room supported the idea that automatic processing should be a user agent's choice, potentially based on user history or explicit consent. The document should encourage user agent control over automation.
- Trust Issues and Senders:
  - Current implementations (e.g., Gmail) use site-wide lists for trusting structured email. This "privileged sender" model was discussed, with some participants expressing unhappiness about it for internet-wide usage.
  - The document should discuss the use of a user's address book for trust.
  - The interplay of DMARC/DKIM with the address book was raised, suggesting that a sender in an address book should also be DKIM-signed to ensure authenticity.
  - Connecting Related Messages: A proposal was made to include a header field that connects an email to older structured data (e.g., booking confirmation to boarding pass) via a unique ID (e.g., UUID and an associated secret). This would allow user agents to trust follow-up messages based on prior user acceptance of a "contract" or relationship. This concept would likely be for a separate mechanism document but should be mentioned as an option in the trust document.
  - Documenting "Bad Practice": There was debate on whether to document existing practices like Gmail's site-wide privileged sender lists if they are not considered ideal. A sense of those present indicated that the document should describe current practices, their trade-offs, and provide recommendations (e.g., discouraging dependence on "privilege" for broad structured email adoption), rather than ignoring them. The goal is to make structured email accessible for diverse senders (e.g., WordPress sites).
- Use Cases and Encryption:
  - The draft notes that some use cases (e.g., medical information) pose higher risks.
  - Encryption: The discussion explored whether encryption should be included.
    - One perspective argued encryption is orthogonal to SML; the content, not the format, dictates encryption needs. Also, a concern was raised about tying SML to "negative buzzwords" like S/MIME.
    - Another perspective argued that encryption should be discussed beyond mere orthogonality, as structured data might warrant encryption independently of its non-structured counterpart (e.g., an encrypted structured health record vs. a link to a website in plain text). This would be particularly relevant for automated processing of sensitive data.
    - A pragmatic view suggested that while email encryption is desirable, its lack of widespread deployment should be acknowledged, and SML should not be tied to it to avoid hindering adoption.
  - A sense of the room indicated that the document should discuss encryption and its effects/non-effects more thoroughly, rather than simply stating it's orthogonal.
draft-ietf-sml-vacation: The vacation draft has been posted as an SML document.
Structured Replies Draft: Philip indicated he is still working on a draft for structured replies and hopes to have something for discussion in the next couple of months.
Next SML Interim Meeting:
- A proposal was made for an interim meeting in mid-February, with a focus on the draft-ietf-sml-base document.
- Hans-Jörg acknowledged the need to prepare updates for the Base Draft.
Email Betterment Meeting (Brussels): Ben announced an informal meeting on January 31st in Brussels, open to all interested in discussing email technologies like JMAP and auto-config.

Decisions and Action Items

Decisions:

The draft-sml-trust-security-considerations document should maintain its descriptive approach, detailing current practices while also discussing trade-offs and providing recommendations.
The draft-sml-trust-security-considerations document must:
- Explicitly discuss new varieties of phishing enabled by structured data.
- Emphasize user agent discretion and choice regarding automatic processing of structured data.
- Include a reference to mechanisms for establishing trust by linking related structured email messages (e.g., via unique IDs).
- Document existing "privileged sender" or site-wide trust list mechanisms (like Gmail's), along with their caveats and a discussion of why they may not be ideal for broad internet adoption.
- Discuss encryption for structured data more thoroughly than simply stating it is orthogonal, exploring cases where it may be relevant.

Action Items:

An: Update the draft-sml-trust-security-considerations draft based on the discussions, specifically incorporating the points agreed upon (new phishing, user agent choice for automation, linking messages for trust, documenting privileged senders/walled gardens, and a more comprehensive discussion of encryption).
An: Following the draft updates, initiate a call for Working Group adoption of draft-sml-trust-security-considerations on the SML mailing list.
Philip: Prepare an initial draft for structured replies for discussion.
Hans-Jörg: Prepare updates and slides for the draft-ietf-sml-base document by February 4th, in preparation for the next interim meeting.
Chairs (An and Alexey): Organize the next SML interim meeting in mid-February, likely focusing on the draft-ietf-sml-base document.
Ben: Facilitate the "Email Betterment" informal meeting in Brussels on January 31st and coordinate logistics with interested attendees.

Next Steps

The draft-sml-trust-security-considerations will be updated and then proposed for Working Group adoption via the mailing list.
The SML Working Group plans to hold an interim meeting in mid-February to discuss the draft-ietf-sml-base document, with Hans-Jörg preparing the necessary updates.
Further progress on a structured replies draft is expected from Philip.