SML Agenda

Minutia

January 2025 Interim

Friday, January 10th, 2025
17:00 (UTC)
1 hours

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=f0c93d0f-ce07-46c1-9444-0d8d34d64ad5

Notes: https://notes.ietf.org/notes-ietf-interim-2025-sml-01-sml

Chair: Alexey Melnikov & Arnt Gulbrandsen

Notes Taker: Ben Bucksch, Alexey Melnikov, Michael Richardson.

1. Note Well

2. Note takers

Trust document

• draft-happel-structured-email-trust-02
• https://datatracker.ietf.org/doc/html/draft-happel-structured-email-trust-02
• Arnt Gulbrandsen presenting
• See slides

• Types of security concerns

  • Phishing: Making user do something, due to specific presentation
    by client

• Automatic processing

  • E.g. add some event invitations directly to calendar. Either at
    receive or display time. -> User approves sender?

• Privileged senders

  • Hans-Jörg: DKIM and addressbook need to be used together, right?
    They are not replacement for each other.
  • Hans-Jörg: Contract / welcome emails, if approved/accepted by
    user, establish a specific relationship / object. Later emails
    about the same object (e.g. contract updates etc) can group
    related emails, and also have a higher trust level. Requires a
    unique password known only to these 2 parties.
  • Phillip: Even with a sequence (transaction) of related emails,
    like an update saying that your flight changed, you need to make
    sure that it is authentic and can update the state of your
    flight.
  • Arnt, Hans-Jörg: Prefer to include inline signing in JSON-LD,
    not S/MIME. Signing of SML payloads would be a separate document
    from this one.
  • Ben: Don't mention Gmail. If we think something is a bad
    process, document to not do that, without mentioning Gmail.
  • Phillip: Can document existing behavior in similar
    circumstances, as well as recommendations.
  • Phillip: The draft can be opinionated. Show best practices.
    Clients can choose to ignore. Document bad practices and why we
    don't recommend it. But important to document.
  • Arnt: Encryption (S/MIME) is orthogonal to SML trust. Explicitly
    out of scope.
  • Alexey, Phillip: I don't think encryption is orthogonal. But the
    document needs to talk about effects it has and doesn't have on
    SML messages. Also talk about "encrypt all representations, not
    just SML". SML content may want to be encrypted even if the
    non-SML version is not (e.g. hospital records may be sent as
    link to health provider website, but SML version may want to
    attach the records directly, in which case it should be
    encrypted)
  • Alexey: I don't think talking about encryption is a blocker for
    adoption, but the final document needs to talk about that.
  • Ben: Agrees with Arnt. We would like to have email encryption,
    but we don't have it yet, for good and very complex reasons,
    which are completely out of scope of the SML WG. If we have
    encrypted emails, good. If we don't, we need to deal with that.
    But cannot force encryption, otherwise the whole SML thing will
    die on the spot.

Other

• Structured replies: Phillip to make a draft in the next few months
• Next meeting Feb 18th: SML Base. Hans-Jörg to implement decisions
  made during Dublin IETF. Hans-Jörg to update draft(s) at least 1
  week before the meeting.
• Friends of email gathering in Brussels on Friday, 31.1.2025, all
  day, directly before FOSDEM. Everybody invited, but please RSVP
  ASAP, so that we can get a conference room of appropriate size.