Minutes IETF117: dispatch
minutes-117-dispatch-00

# DISPATCH Hybrid Meeting @IETF-117

Monday 24 July 2023
Room: Continental 4
09:30-11:30 Local

Log into the IETF datatracker to access:
* MeetEcho
* Notes
* Zulip

DISPATCH Meeting

• Note-taker: Daniel Kahn Gillmor

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

SPIFFE at the IETF (20 min)

Presenter: Justin Richer (On site)

spiffe-spire

SPIFFE is an attestation-based provisioning protocol.
SPIRE is an open-source implementation of SPIFFE.

SPIFFE currently doesn't offer chains of provenance. Could it be something that we want to work on standardizing?

A BoF is to be proposed for IETF118. non-wg mailing list wimse@ietf.org is already running.

Phillip Hallam-Baker (Chat Panel): Form a working group.

Jim Fenton: Messages from the chat panel: Should this work go to Secdispatch or Dispatch?

Justin: Will present this. We are not sure where it goes.

Jim: People believe this is important but "Where" is the question.

Jonathan Rosenberg: Great to see this. We faced a lot of these problems in our cloud software. How many of these are protocols that will cross vendors boundary? Both the software on agent running on Pod and the server are built by the same cloud provider such as Amazon or Google. There will be no need to do the standardization. Why do we need cross-vendor interop?

Justin: SPIFFE is intended to allow to cross vendors, in the spire project deployments with different systems and commercial implementations as well. Two aspects, one is to download a package without needing to depend on a single vendor. the other one is how to have a trust way to match service identification type of thing onto a set of attributes and being able to query that in different cloud.

Phillip Hallam-Baker: There should be a WG-forming BoF. ART or SEC? You can make everything into SEC. The same tried to solve with WS security 20 years ago. We anticipated those usecases but did not have the experience solving simple problems. Better to look at that to see what went wrong.

Justin: Sure.

Atul Tulshibagwale: Two related talks on Wed morning at 9:30, transaction tokens and identity chaining.

Justin: Yes, that is a proposed work in the oauth working group.

Jim: To Justin, a clear way to go?

Justin: Still unclear. To get feedback from both Secdispatch and dispatch. Not just security. The goal is to have a BoF. Working on a set of use case documents, will post to the mailing list soon. Hope to kick the conversation forward.

Murray: If you do this in Secdispatch as well, we should decide which area it should go. It has to be coordinated with SEC dispatch. Will go to that meeting on Tuesday.

Cullen Jennings: We use it for tracking security devices to be able to audit trails when malware is detected. This isn't really "security" work -- the cryptographic work is simple and already solved. This is more about structure and transport, it belongs in ART. (though i don't care if it lands in SEC, either, just coordinate)

Dispatch outcome: Propose a BoF at IETF118, and coordinate with SEC.

SADCDN (20 min)

Presenter: Matt Joras (On site)

SADCDN

Use case: adaptive video traffic shaping (throttling, policing)
existing work (e.g. HLS, DASH)

Inband signals: CN, DSCP, etc.
Out-of-band signals: CAMARA, custom network feedback

Jim: People are clear about the problem. Please focus on the dispatch question: where should this work go?

Matt: Yes, I will talk about it. Side meeting tomorrow at 18:00 in Continental 2-3.

Jim: Is there a online access for the side meeting?

Matt: Yes, on the side meeting wiki.

Ted Hardie: Needs a BoF for the large-scale concern about how explicit signals leak other information. Directly consider the privacy concerns as part of the BoF.

Alissa Cooper: Agree with Ted about the dispatch question. We had issues with CAMARA, what would make it possible to get to consensus in IETF?

Matt: In IETF, the main thing that is better is engagement services. A lot of out-of-band stuff is driven from the operator side. We need consensus between Content endpoints and OEM equipment. There are existing ways for us to work with content endpoints and oem. That is why we think this is potentially an easier way.

Richard Barnes: Can we have signals that go from the network toward the endpoint? It seems like better privacy properties. We might be able to progress more if we just pick one direction of communication.

Matt: We see it goes both way. The two use cases in the draft are directional different. An opportunity to create a single channel for both ways. Want to do something cooperatively. I can see how we might get more consensus if we pick only one direction, though.

Ali Begen: The pacing stuff for traffic shipping has been there for a long time. Farmiliar with the existing work? https://cdn.cta.tech/cta/media/media/resources/standards/pdfs/cta-5004-final.pdf, sister spec: cta-5006, MPEG spec is 23009-5: https://www.iso.org/standard/69079.html

Magnus Westerlund: There are much more use cases around this using this signalling. Discuss more tomorrow.

Harald Alvestrand: The problem is more complicated than you described. The network has to be told which services are using the network. The only way to know is by communicating between the endpoint and the network and the service provider. If not done careful, a lot of information will be exposed. Very complicated problem.

Matt: Yes, it is very complicated. Regarding the leaking problem, it has been done. The shapers already exist today. Traffic is already identified generally by extracting the SNI. Video is specifically being targeted and shaped. But you would only choose the content endpoints which have to be in control of what is shared. It is not true that the bitrate has to be chosen before connection for ABR in general. It is adaptive and is done segment by segment.

Dan Druta: Yes to all the questions on slide 17. It is a good opportunity to look at the problem from different perspectives. The proposal is a bit vague right now in terms of where and how the information is being sent, but we can start from it. Maybe a BoF? To get the ball going.

Dispatch outcome: ART area BoF?

SDP Security Assurance for Secure Real-time Transport Protocol (SRTP) (15 min)

Presenter: Kyzer Davis (On site)

draft-davis-valverde-srtp-assurance

Messages

Rohan Mahy: If they're not willing to implement DTLS-SRTP, why would they be willing to implement this update to SDP?

Kyzer: Solution is very simple, also the library. It is easier to implement.

Draft -00 has one solution, but draft -01 will be submitted with a different approach.

Richard Barnes: Is it an architectural challenge that these parameters are sometimes passed through, rather than generated at the point of emission?

Kyzer: It is the media that is anchored and flowing through device.

Magnus Westerlund: I am one of the co-authors of SDP-die-die-die. Can't we do this with EKT? The information isn't a real secret. The only issue is can you trust this? Wrong information is a DoS vector.

Jonathan Lennox: Not sure this is a good idea. if we're going to do it, Dispatch answer is MMUSIC.

Phillip Hallam-Baker: Trying to sort out WebRTC: it's difficult to find out what is happening and how to keep end-to-end security, especially if some crypto primitives have been swapped out (PQC, threshold crypto). There's too much complexity involved in the ecosystem to be able to safely patch one problem at a time. We should have an overarching bis working group, not tweaking a single spot.

Cullen Jennings: Agree that MMUSIC is the right dispatch. If it's unclear in the spec what happens when the ROC changes, we should fix the spec. Sometimes you have use cases where someone tries to insert a recorder in a session who wasn't part of the call originally.

Jonathan Rosenberg: I'm in MMUSIC. Agree that it's the right place for the work.

Murray: In the MMUSIC Charter?

Jonathan: Yes.

Dispatch outcome: Take this to MMUSIC.

S-Expressions (20 min)

Presenter: Donald Eastlake/Marc Petit-Huguenin (On site)

draft-rivest-sexp

AD Sponsored?

Pete Resnick: Is there a reason for AD-sponsorship over ISE, if it's going to be informational.

Eastlake: No reason one way or the other. Are there directorate reviews if it goes through ISE?

Resnick: Eliot will get appropriate reviewers.

Eastlake: AD-sponsored process seems more lengthy.

Phillip Hallam-Baker: No design scope. The only thing you can do is fix bugs. ISE is best.

Joseph Salowey: ISE or AD-sponsored is fine with me. I'd like to see it to go forward.

Jonathan Rosenberg: It does not need any consensus. Why do we need it at the IETF now? There are other publication venues.

Marc: We're doing this because the reference disappeared from the Internet. Why not go all the way and put it in a stable, permanent archive?

Donald: This will make it more accessible.

Rich Salz: ISE makes sense to me.

Daniel Gillmor: Fine with ISE and AD sponsored as long as it is out there. Please don't extend S-Expressions with this draft, though.

Donald: No there is no extension.

Richard Barnes: We don't really control the ISE in DISPATCH here, but we can say that this is fine for the IETF.

Jim: ISE vs. AD-sponsored? We should hear from AD.

Murray: I'm hearing a lot of support for me not doing this. My queue is very long. ISE will be faster.

Dispatch outcome: Do nothing, but look sideways at the ISE.

Dispatch outcomes summary:

1. SPIFFE: Propose a BoF at IETF118, and coordinate with SEC.

2. SADCDN: Propose an ART area BoF.

3. SDP Security Assurance: Take to MMUSIC.

4. S-expressions: Do nothing, but look in the direction of the ISE.

ART AREA Meeting

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

Richard Barnes: SFrame WG is not meeting, but there is an informal side meeting to check-in. Tuesday at 3pm.

Hans Jörg Happel: Thursday at 2pm, structured e-mail, also on side meeting wiki.

Carsten Bormann: COSE registries are a matter of some conflict. We need something done about it. Carsten will send mail describing the concerns in more detail.

Flextime & AOB (10 min)