# DISPATCH Hybrid Meeting @IETF-115 {#dispatch-hybrid-meeting-ietf-115} Monday 7 November 2022 Room: Kensington 1 9:30-11:30 UTC Log into the IETF datatracker to access: * [MeetEcho][1] * [Notes][2] * [Zulip][3] ## DISPATCH WG Meeting Agenda {#dispatch-wg-meeting-agenda} ### Status and Agenda Bash - Chairs and ADs (10 mins) {#status-and-agenda-bash---chairs-and-ads-10-mins} ### vCon (20 mins) {#vcon-20-mins} Presenter: Thomas Howe & Dan Petrie (in-person) [draft-petrie-vcon][4] [Messages][5] [Mailing list][6] Ted Hardie: It has to go for a BoF. It is a large-scale piece of work. At the BoF, we will want to tackle a very fundmental question: Is this the right lego piece? In IETF, we build building blocks - this is partially built from other building blocks. If you model this with full ontology, this is actually an utterance. This utterance has the identity properties and the linkage of different utterances into time sequence or set of exchanges is what you are calling a conversation. What I want to see all these utterance by this particular identity cross a series of conversions. If we run a BoF, need to be specific on what we're asking people to build. What are the building blocks that are going into this? To back up a step, if we are going to run a BoF, what are we asking people to build? How many pieces are there? Some of the privacy considerations that you have will expand a good bit. Whether or not the identity framework is suitable if you look at from a single interchange may be quite different if you look at from a different perspective. Thomas Howe: Appreciate that, I thought about the same thing and I understand that. When you took the primitives that we already have, they roughly represent the elements that are composite and putting together. But if you think about them from a system diagram, the actual component we think about is externally referenced not from the application layer but regulations from vendors side and it transforms us to the entire ecosystem. We have a lot of requirements on that component, that is what brought me to there. I agree with you. Jonathn Rosenberg: Two comments. One is that it should go for a BoF. Second thing is, unclear but valuable to the BoF, who is this meant to be exchanged between? Needs a system diagram. Clarifying the scope of what are the participants that you want to exchange between, what should be in this or not. Thomas Howe: The 25-page white paper has 15 use cases. How to make it be useful for the BoF? Jonathan Rosenberg: Write a draft on these use cases. Robert Stepanek: Don't want to start bike-shedding, but vCon is a confusing name. Thomas Howe: Started from a joke. If you have a better name, I would like to hear about it. Eric Rescorla: This should go to a BoF clearly. The requisite for a BoF would be a clear problem statement document and a use cases document. Lay out the problem space so people understand what we are trying to solve. Share the problem statement around with other vendors who might be interested. Thomas Howe: Thanks. Martin Thomson: Maybe a BoF is not the right thing to do it. Forming a constituency around this, possibly the W3C might be interested in this work. Thomas Howe: They have reached out. We believe that there were enough privacy and security requirements that were coming from the bottom of the stack, so we suggested it should be part of the problem. It is more a basement than an attic. Martin: Joint work? A lot of higher layer work discribing things like data models. Thomas: Please look at the 25-page white paper. It shows how it applicable to so many different places. Cullen Jennings: BoF. This is very interesting to us. I am Cisco AC rep for W3C. Interested in the use cases that help us manage ML training data. Will this be done on top of semantic web? It will be ignored if so. Jonathan Rosenberg: I don't think that W3C is the right venue. This is like telephony stuff, lots of work on call detail records. Think IETF is fine and it should be a BOF. \*Dispatch outcome: Create draft with use cases, problem statement to clarify scope, and then take to a BoF. ### SASL Authentication for SIP (20 mins) {#sasl-authentication-for-sip-20-mins} Presenter: Rick van Rein [draft-vanrein-sipauth-sasl][7] [Messages][8] Jon Peterson: 10 years ago somebody presented this before for SIP. We kinda come up with security primitives that work for SIP. We have managed most of the security gaps which SASL may rectify, together with STIR. It is a tough sell. No action for dispatch. Rick van Rein: If there's documentation of discussion 10 years ago, would like to see it Eric Rescorla: Dispatch: no action. Do not think this is going to go. As mentioned in email, start with "does anybody who operates a SIP system want to do this". Has anybody deployed this? Rick van Rein: I want to work on it. Eric: does anybody want it? Rick: I think for the wireguard it's a good use case. Eric Rescorla: the question is: does anybody who operates an existing system want to use SASL? If the answer is no, then this doesn't matter. Rick van Rein: For wireshark there's currently no mechanism for setting it up. This adds new venue. Eric Rescorla: Has anybody who operates these systems, e.g. wireguard, want to deploy this? Rick: I will take the question and look around to see if people are interested. Eric Rescorla: On the technical side, this misunderstands the security situation around SIP. We have mechansims that work. The right way to do this is to extend those identity sets with STIR, not by replacing the whole thing. Rick van Rein: I want to use it as domain names. Eric Rescorla: But will anybody who runs a sip system want to use the domain names? Cullen Jennings: Technical comment - when you're talking about end-to-end security, SIP is a hop-by-hop system. You might want to put this security on top of the VPN layer rather than the inherantly hop-by-hop system. Rick van Rein: Will start with wireguard, maybe it needs some work. Anthony Somerset: Operate a large scale voice network (Liquid) - what are we trying to solve? Authenticate caller ID? That the caller is a person on an endpoint? They are two different things with two different problems. It's hop by hop and you have to make routing decisions. Want to echo "authenticate the network layer". But would like to see an alternative to Digest. Might be difficult from a network to network perspective. Rick van Rein: What I am into here is to make a cross-domain call possible. What you said would be a general use case. Thank you for stating that you would like to see a replacement for Digest. Jon Peterson: Didn't want to go technical details but will just a little bit. STIR is not limited to telephone numbers, like RFC4474. If you're concerned about securing TO and FROM, they're usually not controlled by the same party anyway - so figuring out who should attest to the identity. So SASL is not aligned to the problem that SIP is trying to solve. When question is interoperable layer cross domain, we've got that as fixed as it can be with STIR. Rick van Rein: Looking STIR only one RFC? Jon: There are 10-12 RFCs. Rick: I will look into it. DKG (via Jabber): Wireguard deliberately avoids any fancy authentication mechanisms for the sake of simplicity (endpoints are identified by raw public keys). I suspect that wireguard itself will never adopt fancier authentication schemes. Eric Rescorla: Think it's important to distinguish between two things (authenticate client to SIP server) - where SASL is usually used. The other is end-to-end. Think it's inappropriate for this, and peers who work on client-server say that's already solved. My sense is that you like SASL. If you want SASL in SIP, you should look at client to server. Rick van Rein: Need to organise what is actually needed and if this is the solution for that. \*Dispatch outcome: Do not proceed with this work in IETF. ### DKIM replay (20 mins) {#dkim-replay-20-mins} Presenter: Wei Chuang (virtual) and Bron Gondwana (in-person) Four draft solutions to a common problem: * [draft-chuang-dkim-replay-problem][9] * [draft-chuang-replay-resistant-arc][10] * [draft-gondwana-email-mailpath][11] * [draft-bradshaw-envelope-validation-extension-dkim][12] * [draft-kucherawy-dkim-anti-replay][13] [Messages][14] Murray Kucherawy: Is anyone using any of these yet? Bron Gondwana: Yahoo is using. It is not a perfect solution though. There are a lot talks about it. People are trying to find out the right solution. Barry Leiba: Former DKIM WG chair. We discussed about this issue a lot in the original DKIM design, but we could not resolve it. We now have more information and operational experience. We know about the priorities and ability to compare the different proposals. So it is important to look at this. A new WG is the right venue. Eric Rescorla: There seems enough energy behind this. A new WG seems good. Jim Fenton: This is something that was considered in the design of DKIM. The requirement for confidentiality of BCC recipients in the same domain should also be considered. This is an interesting problem to solve. Whether it is a solvable problem with all the constraints without breaking something? Bron Gondwana: This question has been answered in several drafts. Each BCC recipient can only see their own address not others. That solves it. It is not a big cost now. We consume it is required because computer is fast and it is not a problem now. Jim Fenton: Gmail has enough capacity to handle the additional incoming mail? This is also a burden on mailing list. Bron Gondwana: It is already happening. Wes Hardaker: Agree with Eric, these problems get bigger and bigger. This is big enough of a problem to require a WG, will consume 2 hours every time we meet. But how will this evolve over time? Work needs continous discussions and measure how things work. It seems to me that a longer term maintanence WG is needed as well. Bron Gondwana: Agree. In the next couple of years, we need to talk with the ADs to consolidate several email WGs into a maintenance WG. AD, do you want to comment on that? Murray Kucherawy: We have talked about that. There is a related concern. A lot of drafts are heading to ISC because there is not a maintenance working group. It can also turn into the ocean boiling so we need to control it properly. The conversation is happening. It sounds that people are OK to start a WG without a BoF? If anybody wants to chair it please let me know. Cullen Jennings: A lot of people in this room don't believe the problem solvable. BoF would provide an opportunity to discuss the problem and to see whether this problem is solvable. We tried to solve this problem many times before but we failed. We need a BoF to see whether there is anything that has changed fundamentally. Barry Leiba: To Cullen, what has been changed is that we have more experience with using DKIM. We know about the more important use cases than those ones which we can compromise on. Why we did not want to do the solution before can be re-evaluated to see now whether we can say now these use cases are less important. Cullen Jennings: That make sense. But there is no discussion on any use case. This is missing. Barry Leiba: That is up to the WG to solve. Kirsty: Have heard no-one but Cullen ask for a BoF before the WG forming, if you disagree and think a BoF is needed - please join the queue now and express that view. Given no-one joined, will say that is not necessary and the WG can be formed directly. DKG (via Jabber): I'd hope that a WG could consider recipient-controlled permissioning something like ORCA (https://www.usenix.org/conference/usenixsecurity22/presentation/tyagi), to accomodate opt-in situations like the mailing list use case \*Dispatch outcome: Form a new WG without a BoF for this problem. ### WebRTC-HTTP Egress Protocol (WHEP) (10 mins) {#webrtc-http-egress-protocol-whep-10-mins} Presenter: Sergio Garcia Murillo, Cheng Chen [draft-murillo-whep][15] [Messages][16] Cullen Jennings (Jabber): I can't figure out how to get on the q anymore but +1 on recharter WISH WG to do this Murray: Has this been discussed at WISH? Sergio Garcia Murillo (speaker): It is in the agenda for this Thursday. We tried to present in the last IETF meeting, but only 5mins. It is difficult to discuss something that is not in the charter of the WG. Hope we could get the WG to rechartered so we could get it into the agenda. Murray: We'd better to wait for the outcome from WISH meeting. Sean Turner (Chair of WISH): We have 5 minutes to talk about it last time, we have a 30 minute session on it in the WISH WG session this week, so let's see if that's in scope. \*Dispatch outcome: wait for the outcome from WISH WG discussion this week. ### Dispatch summary: {#dispatch-summary} * vCon: Create draft with use case, problem statement to clarify scope, and then take to a BoF. The vCon bar BoF is on Thursday 15:30-16:30 in Richmond 6. * SASL Authentication for SIP: Do not proceed with this work in IETF. * DKIM replay: Form a new WG without a BoF for this problem. * WHEP: Wait for the outcome from WISH WG discussion this week. ## ART AREA Meeting {#art-area-meeting} * * * ### BoFs, updates and meetings of interest - ADs (10 mins) {#bofs-updates-and-meetings-of-interest---ads-10-mins} Murray Kucherawy: If there's anything in my queue that I haven't acknowledged, let me know. ### NGI funding for Internet open-source activities (5-10 mins) {#ngi-funding-for-internet-open-source-activities-5-10-mins} Presenter: Stephen Farrell [Slides][17] Stephen: mostly just raising awareness of funding, no questions. ### eBPF: Advertisement for Thursday side meeting (10 mins) {#ebpf-advertisement-for-thursday-side-meeting-10-mins} Presenter: Dave Thaler [Slides][18] David Schinazi: I used to think IETF should not standarise API. IETF has changed. I think it is important. If you make your analogy with JavaScript work, that would be amazing. IETF would be a good place. Dave Thaler: Encourage you to go to the Side meeting. Eric Rescorla: This is good stuff. I'm less excited about having it at IETF, purely for cultural reasons. Like this requiring knowing how JITs work, different languages, verification etc. Possibly looking at what was done with TC-79, in W3C, that had the community (bringing a lot of JIT compiler folks together), very intense working mode culture. Want to emphasise this is exciting work and I'm glad it's happening. Will avoid "drop-in tourism". Dave Thaler: My counter is this is widely deployed and not standardised. There's a bunch of people already out there in the community that do this but they are not "IETF people". I would like to encourage more interaction between these communities, regardless of where this happens. Eric Rescorla: Requires care and feeding. Dave Thaler: It is not yet mature and still evolving. It depends on how fast the IETF's proceedures are. To get everybody in the same room could help. Harald Alvestrand: What's your perception of the relationship between this and WASN? And the two dev communities? Dave Thaler: I don't know WASN well enough to know the difference. Is one used more in kernel space, rather than user space? Eric Rescorla: Does not have the proof stage that this has. Part of the proof is about verifying termination. DKG (via Jabber): Don't knock standardizing APIs -- we need APIs to be able to communicate the properties we believe we are offering to the upper layers. Side meeting is on Thursday at 6pm. ### The Hypertext Transfer Protocol Attestable (HTTPA) Version 2 (5 mins) {#the-hypertext-transfer-protocol-attestable-httpa-version-2-5-mins} Presenter: Hans Wang [draft-sandowicz-httpbis-httpa2][19] [Messages][20] Eric Rescorla: In the diagram shown in slide 4, how much of the webservers is running in the TEE? Hans Wang: In this use case, we only demonstrated one. Eric Rescorla: Is the entire webserver running in the TEE or just a tiny bit? Hans Wang: It could be either one. It depends on how you design the webservice scope. Alex Chernyakhovsky: Why are we doing this rather than an attestable TLS? What are the benefits by putting this at the HTTP layer, now every service needs to be aware of the attestion? Could not see any benefit and how this will be used in the wild. Hans Wang: The key motivation is to build the trust inside the TEE. We don't trust anything outside of the TEE. The best way is to implement at the high level like L7. Alex Chernyakhovsky: I don't think so. You could simply implement TLS mutual authentication inside the TEE. Hans Wang: In that case, you will have to implement everything inside the application gateway. The implementation will be difficult. Alex Chernyakhovsky: Your goal is to have an untrusted gateway and have the TEE do the verification. You don't want to do the sni-based routing or anything else? Hans Wang: Those routing can happen. We want to make sure that the confidentiality of the message can be protected. Dave Thaler: (Chair of TEEP) I have seen at least five different proposals in the CCC metings. Don't think TEEP is the right place since it is for provisioning as opposed to the actual communications here. RATS is a good group to review it. Martin Thomson: This is on the agenda for the secdispatch this week for 5 mins. I suggest to take this discuss to that meeting. We could better answer the questions. Hank: First go to the HTTP first and then RATs to review the protocols if needed. ### Flextime & AOB (5 mins) {#flextime--aob-5-mins} [1]: https://wws.conf.meetecho.com/conference/?group=dispatch [2]: https://notes.ietf.org/notes-ietf-115-dispatch [3]: https://zulip.ietf.org/#narrow/stream/43-dispatch [4]: https://datatracker.ietf.org/doc/draft-petrie-vcon/ [5]: https://mailarchive.ietf.org/arch/msg/dispatch/ckJJH2fs47UBgHVR2OZEwkQ4CMc/ [6]: https://mailarchive.ietf.org/arch/browse/vcon/ [7]: https://datatracker.ietf.org/doc/draft-vanrein-sipauth-sasl/ [8]: https://mailarchive.ietf.org/arch/msg/dispatch/b_bp4zjWOnTuykf85NfIV8DGHrs/ [9]: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ [10]: https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ [11]: https://www.ietf.org/archive/id/draft-gondwana-email-mailpath-00.html [12]: https://www.ietf.org/archive/id/draft-bradshaw-envelope-validation-extension-dkim-00.html [13]: https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-anti-replay-01 [14]: https://mailarchive.ietf.org/arch/msg/dispatch/7_R0Sh69zzVk74Chj_UUZYmme3k/ [15]: https://datatracker.ietf.org/doc/draft-murillo-whep/ [16]: https://mailarchive.ietf.org/arch/msg/dispatch/RzUARP6j2zYASducwj8kb8pJATs/ [17]: https://datatracker.ietf.org/doc/slides-115-dispatch-ngi-eu-funding/ [18]: https://datatracker.ietf.org/doc/slides-115-dispatch-ebpf-advertisement-for-thursday-side-meeting/ [19]: https://datatracker.ietf.org/doc/draft-sandowicz-httpbis-httpa2/ [20]: https://mailarchive.ietf.org/arch/msg/dispatch/9HB7fnQHPQ6-nglJJorf80GmRss/