15:32:36 <RRSAgent> RRSAgent has joined #multicast
15:32:36 <RRSAgent> logging to https://www.w3.org/2021/12/01-multicast-irc
15:33:42 <cpn> Meeting: Multicast CG
15:34:02 <cpn> Present: Jake_Holland, Kyle_Rose, Casey_Russell, Chris_Needham
15:34:07 <cpn> Chair: Jake_Holland
15:38:03 <cpn> Topic: Introduction
15:38:42 <cpn> Jake: Can we move this meeting by 30 or 60 minutes, it's too early for some
15:40:21 <cpn> ... Will ask on the mailing list, to give others the change to respond
15:40:31 <cpn> ... Tentatively, we'll move the meeting 2 hours later
15:41:15 <cpn> Topic: Group update
15:41:33 <cpn> Jake: We had the TPAC meeting, which aired complexity in getting the adoption we need
15:41:50 <cpn> ... Input from Eric was to get more people involved, in particular the browser vendors
15:42:17 <cpn> ... Some ISPs are on board, others in the group that haven't joined meetings but I talk to separately
15:42:42 <cpn> ... It's a challenge for people at ISPs to work towards browser development
15:43:15 <cpn> ... Getting it into the browser is the step that makes it interesting, as there's then a receiver that everyone can use
15:43:30 <cpn> ... No change on the position about getting consensus on security
15:43:55 <cpn> ... So we're on the right track. It's not easy, but we're trying to do the right things
15:44:31 <cpn> Casey: I think you're right that getting it into the browser is critical. We're enthusiastic about helping
15:44:56 <cpn> ... You're right that it's hard for us as a network to help on the browser side, we don't have people in that area
15:45:23 <cpn> Jake: The other event recently was IETF. I presented at SecDispatch and MBONED
15:45:47 <cpn> ... We're dispatched to the MSEC list for further discussion. This group was closed a few years ago but the mailing list is still there
15:46:31 <cpn> ... Questions about whether to use MSEC or a new list. Got feedback from an Area Director that MSEC list was a good place
15:46:55 <cpn> ... So I'll start a discussion there. Please consider joining the list to join that discussion
15:47:11 <cpn> ... Some input from ekr, and good discussion during the session
15:47:30 <cpn> ... To summarise, people who are into security are skeptical of this
15:48:08 <cpn> ... ekr reviewed the draft, seemed to think it's not a good idea, but didn't give specific concerns, more that browsers aren't interested so why bother?
15:48:32 <cpn> ... I had similar responses from others at browser implementers
15:49:15 <cpn> ... It would help to have the WebTransport integration running. Feedback from Martin Thompson that we need to have an actual protocol with security properties before we can reasonably discuss it
15:49:45 <cpn> ... The security considerations document describes what we need to achieve for the protocol, and makes sense as a separate doc
15:50:00 <cpn> ... Want to get to a first stage proposal for how to do secure transport in WebTransport
15:50:53 <cpn> ... Another thing was origin-linked authentication, dispatch to CDNI. That might be worth exploring. I'll see if we can do something with datagrams in WebTransport first
15:52:40 <cpn> Chris: Concerned about lack of browser interest? Is it because they think the security aspects aren't solveable or other reasons?
15:53:03 <cpn> Kyle: I think it could be that this doesn't fit the current mental model of the web
15:54:07 <cpn> Jake: The reason people are skeptical is that it's viewed as challenging, and their default position is that it's not worthwhile
15:54:16 <cpn> ... Most haven't commented yet on the claims about traffic or energy savings, so they may not have considered it yet
15:55:40 <cpn> ... When you can't deliver to a browser, and it's a high volume event, instead you use a TV station approach: send to the ISP who sends it on to customers
15:56:26 <cpn> Kyle: So the alternative is not that we won't do it, but it'll be delivered in a proprietary manner that doesn't benefit from an IETF or W3C collaboration
15:56:55 <cpn> Jake: Hope to do this for game delivery, also smart TV devices for some specific content owners
15:57:36 <cpn> ... It's a concern that people can find out what content is being delivered. That's discoverable already, covered in TLS specs as something TLS is vulnerable to
15:58:02 <cpn> ... You can defeat it but by making content look identical, so everything has to be at the size the largest
15:58:23 <cpn> ... People aren't willing to do that, as it increases amount of traffic
15:58:57 <cpn> ... By saying we can't use multicast, you have to use 30x amount of traffic instead
15:59:24 <cpn> ... There's a problem of getting people to take multicast seriously, which we go through with each group that looks at it
15:59:47 <cpn> ... Let's find out where the real user threats are. I don't want to diminish concerns
16:00:40 <cpn> Jake: The simple argument to make it part of the web security model should be added to the doc
16:00:46 <cpn> s/Jake/Kyle/
16:01:01 <cpn> ... Some that are interested in this question would be responsive to that
16:01:39 <cpn> Jake: It's a point that Lucas raised, reminiscent of DNS becoming a privacy considerations thing over the last 8 years
16:02:29 <cpn> ... So there's an analogy here. There is multicast traffic today, but not known who's analysing it. So if there's a privacy problem it exists today
16:02:54 <cpn> ... I agree it should go into the document. Would you be able to raise an issue?
16:02:58 <cpn> Kyle: Yes
16:03:37 <cpn> Jake: Hoping to get discussion going, not sure we'll be ready for a BoF by next IETF
16:04:21 <cpn> ... In parallel, I'll be doing the Web Platform Tests for WebTransport, to get together a strawman protocol
16:04:39 <cpn> Topic: Dual Stack Relays
16:04:59 <cpn> Jake: There's some test traffic available
16:05:24 <cpn> ... 23.212.185.2 -> 232.1.1.1:5001 and 23.212.185.2- > 232.1.1.1:5001
16:06:15 <cpn> ... I might set up VLC so there's something running all the time
16:06:37 <cpn> ... The relay is theoretically running dual stack
16:07:25 <cpn> ... The IPv6 work is taking longer than I'd wished. There's challenges at the AWS level, but then in it's not behaving the same in the device
16:08:48 <cpn> ... Setting the route isn't sufficient with IPv6. If I set up as a separate device, multicast traffic won't flow so you have to tunnel it
16:09:04 <cpn> ... Don't know why routing isn't behaving as expected yet
16:09:51 <cpn> ... I'm hoping to have it running. Please let me know if you'd like to work on this with me, to help troubleshoot
16:10:18 <cpn> ... I have the relay discovery working, so lookup with reverse IP of source address does find the relay
16:10:43 <cpn> ... I want to get onto the QUIC and WebTransport part
16:11:17 <cpn> ... IPv6 is important, as I know people want it, but it's not my core mission
16:11:27 <cpn> Topic: Next steps
16:11:48 <cpn> ... Kick off MSEC discussion, start on WebTransport. Hope to have more for next meeting
16:12:29 <cpn> ... Casey, were you interested in setting up ingest?
16:13:24 <cpn> i/... The IPv6 work/... 2600:14e0::2->[ff3e::8000:1]:5001 and 16:09 2600:14e0::2->[ff3e::8000:1]:5001/
16:13:56 <cpn> Casey: Let's set a time to do that
16:14:57 <cpn> Chris: Outcomes from the Second Screen meeting?
16:15:37 <cpn> Jake: Interesting conversation, but inconclusive. They had looked at privacy considerations, but not whether it's necessary to do things like disable it in private browsing mode
16:16:17 <cpn> ... We should circle back with them, to see if there was any follow up. They had other questions around TLS connections to local devices, some discussion in GitHub
16:17:00 <cpn> ... Some who were there joined the TPAC Multicast CG meeting. There's overlap with the privacy considerations in terms of discoverability of local devices
16:17:47 <cpn> ... There was an MBONED presentation from Apple on protections against local discovery, so user permission is needed before an app can access APIs that do local network discovery operations
16:18:32 <cpn> ... Other protections, e.g, pre-register at build time to say what services or names you're app will use, and then Apple have control over that
16:19:29 <cpn> ... The second screen privacy considerations are similar. It's not just multicast itself but also the local device discovery
16:20:01 <cpn> ... He didn't talk about what the abuse is, but there's an abundance of caution, principles of data minimisation
16:21:51 <cpn> ... I didn't see anything super helpful. I feel that there's a gap where nobody has a great understanding of what's necessary to achieve. Push-back on exposing information that potentially introduces new threat models
16:22:57 <cpn> ... We're not solving the same problem, but some commonality with privacy considerations
16:23:44 <cpn> rrsagent, draft minutes
16:23:44 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/01-multicast-minutes.html cpn
16:24:30 <cpn> rrsagent, make log public