DISPATCH Hybrid Meeting @IETF-113

Monday 21 March 2022

Grand Park Hall 3

10:00-12:00 UTC+1

MeetEcho

Notes

Jabber

DISPATCH Meeting

Status and Agenda Bash - Chairs and ADs (10 min)

No bashes to the agenda

Complaint Feedback Loop Address Header (20 min)

Presenter: Jan-Philipp Benecke

draft-benecke-cfbl-address-header
Slides

Messages

• John Levine: reasonable proposal, useful experiment. Work should go forward, AD-sponsored.
• Bron: lots of email work coming at the moment, worth a WG for handling email work. Issue with DKIM replay attacks, don’t think this fixes that and will cause reputation problems for the sender - need to a. Think we should look at opening a WG or else AD sponsored
• Murray: will share in chat.
• Cullen: security issues raised means it’s too complex for AD sponsorship. Suggest WG creation.
• Murray via Jabber: On this draft: We are discussing the idea of having an “email maintenance” working group to cover this and other work that has been coming lately, but can’t go to any of the current email working groups.
• John Klensin via Jabber: The difficulty with another mail WG is that there does not seem to be adequate energy in EMAILCORE to do much work on-list. If a new WG, with more interesting topics than polishing old specs, further diluted that limited energy, it would not be good news.

DISPATCH outcome: work should go forward, possibly under new WG for wider email maintenance if the community has interest - creation to be led by Murray.

A well-known URI for publishing ECHConfigList values (20 mins)

Presenter: Joe Salowey

draft-farrell-tls-wkesni/

Messages

• Alexey: this is a cross between ART and SEC -> maybe take to HTTP WG.
• Ted Hardie: Think the dispatch question depends on whether you generalise it or not. General would be useful, in which case a short-lived working group. Depends on whether DNS side or HTTP side - different caching standards.
  • Think submission to AD but review by HTTP if just this one.
• Martin Thomson: Not sure if generalisation is necessary. Solution will require a bit more thought. This needs to go to a WG. Unsure if http or tls, probably http. Would like people who are looking to operate this kind of service to give feedback.
• Pete Resnick (Jabber): Seems like put it in TLS and get ARTART to look at it early. (Stephen Farrell agrees)
• Mark Nottingham: This is not what the HTTPAPI group is for, would not like to burden it with this. Maybe, there’s a lot going on in this general space. Wherever the implementers are.
• PHB: This might be more complicated than is being made out. Might be able to do this in TLS, or different WG on its own. Doesn’t fit into the way of doing TLS or HTTP in the past. Got to step back and rethink how we use DNS. Need to rethink how we use SRV records in DNS.
  • Joe: do you think this is a more general problem?
  • PHB: Yes, we are lacking generic secure service discovery in IETF, have for 20 years. There should be a way to find a host reliably from an identity. Host, protocol, versions, etc. Should have done this as an IETF-wide resource that everyone is encouraged to use. Should subsume well-known, etc.
• Rich Salz: representing a CDN. Very worried about a general-purpose solution. Any customer who uses a CDN (or multiple CDNs) - want to make it easy for them configure. Let’s do this, and generalise after a second similar case. Suggest dispatch to DNSOP. Meets pressing need in industry.
  • mnot (Jabber): I’m not sure I want DNSOP designing HTTP APIs…
• Eric Orth: Generalise to the level below, and generalise at least at the SVC record level. Extremely generalised case and should be dispatched at that level.
• Sean Turner (TLS chair): TLS WG thought this wasn’t really just TLS, they try to focus on TLS wire format -> not the right people in the room.
• Francesca Palombini: Haven’t heard a clear consensus in jabber and room -> have heard that it needs a WG, will not go to AD sponsored. Probably not a new WG. Maybe we can continue with discussion on mailing list.

DISPATCH outcome:

• Interest in the work, but not clear which WG (DNSOp, TLS, HTTPBIS all suggested) or area (ART or SEC). Discussion on dispatch mailing list.

Updated Use of the Expires Message Header Field (10 mins)

Presenter: John Levine

[draft-billon-expires](https://datatracker.ietf.org/doc/draft-billon-expires

• Alexey: like this, represent a vendor who implemented it in X400. Sounds sensible. Surprised it wasn’t defined for internet mail already. Emailcore might be an option (John points out the slide says absolutely not)
• Sean Turner: not much dispute about this. Generally mail community is noisy if there’s dispute. Can we just AD sponsor?
• Michael Welzl: support for this, will be great to have a standardised way of doing that
• Rohan Mahy: think it’s useful. No view on dispatch.
• Kirsty: any issues with AD sponsorship as an outcome? Speak now or else that’s the outcome… no views. AD-sponsored.

DISPATCH outcome:

• recommend for AD Sponsorship

Inside MLS Message Interop (IMMI) (10 mins)

Presenter: Rohan Mahy

draft-mahy-dispatch-immi-content

draft-mahy-dispatch-immi-mls-mime

Messages

• Martin Thomson (Jabber): it would be really good to understand how this approach differs from that the sframe WG is considering.
• Harald: having ability to know format of the code that you’re sending is useful, but doesn’t mean you understand the semantics. Semantics are complex to specify and make interoperable. Systems devolve into islands of their own.
  • Rohan:
• Richard Barnes: this document is a bit premature. This is a bigger challenge. BoF instead of advancing these docs directly.
  • Rohan: two documents here, think this was mostly about content-type. Please say which draft you’re thinking about, or both.
  • Richard: immi-content more straightforward.
• PHB: Finding it interesting. We’re supposed to be doing stuff that interoperates for the end user. Messaging is more wall gardens. Didn’t like that MLS was walled gardens. This is interoperable messaging system without building fully interoperable. Can’t say it’s interop if you can’t have people on two different services able to talk to each other. Should only spend time on if it’s for users. Support BoF, but only for interoperable from point of view of users.
• Martin Thomson: How do you imagine the use of keys coming our of MLS being used? Also suggest BoF.
• Francesca Palombini for Ben Schwarz: why MIME not ALPN?
• Francesca as AD: WG forming BoF, or discussion?
• Cullen Jennings: am interested in the high-level problem here. In terms of email (as an anology) can solve the SMTP problem, not the IMAP problem. How services move data between them, not how the clients get the data. Lots of companies and services have worked on this, cross-system data. Lots of need for end-to-end encryption. Think we can use MLS to do things end-to-end, but current gateways won’t work any more, so we need to solve the problem of how to do end-to-end. Support a BoF, but think we’re moving way too slowly in this space, so interim virtual BoF, working group forming. Don’t need to be gated by two more meetings.
• Pete Resnick: Want to agree with Cullen, WG forming BoF ASAP. Have players in the room who are working on the products. Do we have anyone in the industry willing? Maybe Facebook? Wire.

DISPATCH Outcome:

• WG-forming BoF

Open Ethics Transparency Protocol (20 min)

Presenter: Nikita Lukianets

draft-lukianets-open-ethics-transparency-protocol

Messages

• asked to be moved to later in the agenda…

• On at 11:10.

• On Jabber - definitely not AD-sponsored. Too complex.

• Richard Barnes: Q: who is interested in taking this work on? Do you have examples of people interested in publishing this?

  • Nikita: started work with people who want to showcase these labels. Want to start with smaller companies.
  • Even if vendors’ processes are transparent, they don’t have a clear way to show.
  • EU has showcased these ideas as a way to make GDPR, etc practical. Regulator could do more than just punishing, do education. Right now no tools for regulators.

• Pete Resnick: think it’s very interesting stuff. There’s a lot of pieces in the draft. Some are potentially protocol or data format -> technical work that we can do engineering on, but a lot of other moving pieces. If this goes forward, it would have to be a BoF forming working group, but not pulled apart into the pieces that the IETF could work on.

• Patrick Tarpey: from OFCOM. Having a unified/baseline view of what ethics looks like across the globe is challenging. PII is established in EU for GDPR, but outside EU even that definition is unclear. If we provide end users with information attested by a third party. What’s the process if the user doesn’t agree? Who pays for third party auditing? Anything that allows people to make informed decisions is good, but how do we get a base minimum that works globally?

  • Nikita: trying to avoid unification of ethics. This is just a description of how products operate, so the user can select products that match their wants.
  • Third party verification by auditors should be paid by the companies which see the profit from selling the product. There is a project which allows end user to give social feedback on products that are not doing what they claim.
  • Avoiding universal ethics.

• Ted Hardie: Thank you for bringing the work, it’s very interesting and very broad. You talk to the visual representation, the ecosystem, who validates and it’s very large. That’s more for systems engineering groups, a whole release for the whole system to deliver the service to the end user. The IETF takes requirements from those groups and then makes the protocols that make the systems work. Right now, I think you need build a new group! Of people who will come together and define the whole system. That group in turn can send the lego pieces of protocol design to the IETF when it falls in our purview. This is the kind of work that the IETF would get bogged down in the protocols, not the system.

  • Kirsty: chat on Jabber that maybe IETF is not the place (yet) for this work.

• Leif Johansson: there are very similar things done in “Consent Receipts”.

DISPATCH outcome:

• This is interesting work and a good problem, but a bit big for the IETF in its current form. Work with the community/on the dispatch list to work out the IETF-specific parts of this ecosystem.

ART AREA Meeting

BoFs, updates and meetings of interest - ADs (10 min)

Event Streaming Open Network (20 min)

Presenter: Emiliano Spinella

Messages

draft-spinella-event-streaming-open-network

BOF request (failed)

NEXT STEPS:

• Event Streaming Open Network side meeting is on Wednesday 23rd at 16:00 in Grand Klimt Hall 3.

AOB

• ECMAScripts - dispatch WG document was AD sponsored and is with the RFC Editor
• Francesca: Email stuff group is with RFC editor.

Bron has 3 problems in the email space slides:

• Rcpt-To - avoid DKIM replay attacks
• ARC
• send large file via email

Barry Leiba: spent a lot of time in the DKIM working group, couldn’t come up with anything that worked with the parameters they had. Issue with BCC and privacy exposures, tying with SPF.

Best thing you can do is reduce the window by expiring keys.

DMARC is basically ADSP with recording. Failed for exactly this reason, that organisations were using it in ways it wasn’t intended to be used. DMARC wasn’t supposed to be used in the way it’s been used.

Summary

DISPATCH outcomes:

• Complaint Feedback Loop Header: work should go forward, possibly under new WG for wider email maintenance if the community has interest - creation and next steps to be led by Murray (AD).
• ECH Config: Interest in the work to progress, but not clear which WG (DNSOp, TLS, HTTPBIS all suggested) or area (ART or SEC). Discussion on dispatch mailing list.
• Updated Use of the Expires Message Header Field: recommend for AD-sponsorship
• IMMI: WG-forming BoF
• Open Ethics: Interesting work and a good problem, but a bit big for the IETF in its current form. Work with the community/on the dispatch list to work out the IETF-specific parts of this ecosystem.

ART Area:

• Event Streaming Open Network side meeting is on Wednesday 23rd at 16:00 in Grand Klimt Hall 3.