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)
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/
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.
Ran out of time to discuss this.