SML Agenda

IETF 120 [hybrid] Vancouver

Tuesday, July 23rd, 2024
15:30 (Vancouver, UTC-7)/22:30 (UTC)
1.5 hours

Meetecho:
https://meetings.conf.meetecho.com/ietf120/?group=sml&short=&item=1
Notes: https://notes.ietf.org/notes-ietf-120-sml

Chair: Alexey Melnikov & Arnt Gulbrandsen

Notes Taker: Jim Fenton

Agenda

• Administrivia - Chair
  Note Well and Code of Conduct presented.

• Structured Email: Use cases - Hans-Jörg Happel
  Preliminary privacy and trust discussion added for use cases.
  Example: location info (perhaps high privacy but low trust)
  Alexey: will there be more examples?
  Next steps: modeling guidance, novel use cases

• Structured Email - Hans-Jörg Happel
  Main specification for structured email
  Updates since 119: non-representation case (i.e. "I am going on
  holidays in 1 week" attached to a regular email)

• legacy structured email survey: different representations (2
  responses so far; want more). Tool for extracting data will be
  published.

• multipart/alternative survey: Support for other combinations besides
  plain text and HTML. Some systems won't allow others.
  Philip Tao: Have you considered MIME header representation for
  short things like one-time codes?
  ACTION: Alexey to create a ticket for this.
  Pete Resnick: comment in chat to use multipart/related doesn't
  make much sense. Sometimes don't want a plaintext representation.
  Does VPIM have some useful header field for signaling a hint (type
  of data)? Maybe a SHOULD to provide a hint. (Pete later found that
  it was "Message-Context" header field)
  Daniel Eggert: Suggestion to pull out a summary of a potentially
  very long email part.
  Ken Murchison: +1 to having a top-level header field saying
  where to find specific parts (iMIP):
  https://datatracker.ietf.org/doc/draft-daboo-imip-headers/
  dkg: also supports multipart/alternative or structured header at
  the top. Less worried about existing API abilities to generate
  multipart/alternative messages than ability to consume them, as
  incentives are different.
  Lyndon Nerenburg: Should be a stand-alone MIME part. Avoids
  having to fiddle with HTML. Medical use case has needs for high
  security/privacy. "Forwarding scares me to death."
  Daniel: not needed to download and parse HTML is a good thing,
  reduces the amount of work (and memory) needed by MUA
  Alexey: IMAP/JMAP have a way to let MUA only download a specific
  body part within multipart/alternative, which is again more
  efficient than downloading the whole message.
  Trent Adams: Questions about provenance around who put what into
  the message. (This is a case of an intermediary inserting such data,
  not the sender.) Will write up use case; helpful if provenance info
  is adjacent to part it refers to.

• The current list of open issues:
  https://github.com/hhappel/draft-happel-structured-email/issues/

  • Discussion

• Structured Email: Trust and security considerations - Arnt
  Gulbrandsen
  Updated since IETF 119, considerably different focus. Existing
  practice, less advice.

Daniel: Should the document talk about use of DKIM for validation of
authenticity?

Arnt: Also Authentication-Results header field?

DKG: end-to-end email encryption enthusiast: use the cryptographic
signatures and LAMPS Header Protection document. Can't always trust mail
servers.

Philip: clients and servers can be from different organizations, so
clients not trusting their servers is a consideration. Are concerns
about forwarding addressed in the documents?

Automated processing is a concern, dkg's cc case is an example.

Ben: what implementation do now is not necessarily what we want to
do in the future. For exampple the trusted sender concept.

Michael Slusarz: Are these problems specific to structured email? It
sounds like many of these are problems for email in general.

Ben: Think about "what is worse than HTML."

Pete: In html, we sandbox, etc. There are new contexts here that may
not have covered these issues as well.

Hans-Jörg: We are required to work on Trust/Security document by
charter.

Alexey: We have moral obligation to discuss this :-).

Mechanisms (encryption, trust)
Philip: Maybe some tradeoffs with encryption, like need to download
entire message.

Daniel: Already can send calendar invites, etc. Shouldn't invent
another encryption mechanism for this. (Alexey says we're not doing this
anyway).

DKG: Add a reference to LAMPS e2e encrypted email guidance draft
https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/

Trent: per body part encryption, as some body parts might need more
protection than others

Jim: I am getting worried when "DKIM" and "trust" are used in the
same sentence. DKIM is limited in what it can achieve.

dkg: Pushing back on Trent per body part encryption proposal. See
discussion in LAMPS WG on why not, don't do it here.

• Structured vacation notices - Hans-Jörg Happel

Ran out of time to discuss this.