IRC log of multicast on 2021-12-01

Timestamps are in UTC.

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