Meeting minutes
Introduction
Jake: Can we move this
meeting by 30 or 60 minutes, it's too early for some
… Will ask on the mailing list, to give others the
change to respond
… Tentatively, we'll move the meeting 2 hours
later
Group update
Jake: We had the TPAC
meeting, which aired complexity in getting the adoption we
need
… Input from Eric was to get more people involved,
in particular the browser vendors
… Some ISPs are on board, others in the group that
haven't joined meetings but I talk to separately
… It's a challenge for people at ISPs to work
towards browser development
… Getting it into the browser is the step that
makes it interesting, as there's then a receiver that everyone can
use
… No change on the position about getting consensus
on security
… So we're on the right track. It's not easy, but
we're trying to do the right things
Casey: I think you're
right that getting it into the browser is critical. We're
enthusiastic about helping
… 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
Jake: The other event
recently was IETF. I presented at SecDispatch and MBONED
… 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
… Questions about whether to use MSEC or a new
list. Got feedback from an Area Director that MSEC list was a good
place
… So I'll start a discussion there. Please consider
joining the list to join that discussion
… Some input from ekr, and good discussion during
the session
… To summarise, people who are into security are
skeptical of this
… ekr reviewed the draft and seemed to think it's
not a good idea, but did not sustain any technical objections
during discussion,
… and moved in the end to the observation that
browsers aren't interested and implying it's not
worthwhile
…
https://
… I had similar responses from others at browser
implementers
… 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
… The security considerations document describes
what we need to achieve for the protocol, and makes sense as a
separate doc
… Want to get to a first stage proposal for how to
do secure transport in WebTransport
… 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
Chris: Concerned about lack of browser interest? Is it because they think the security aspects aren't solveable or other reasons?
Kyle: I think it could be that this doesn't fit the current mental model of the web
Jake: The reason people
are skeptical is that it's viewed as challenging, and their default
position is that it's not worthwhile
… Most haven't commented yet on the claims about
traffic or energy savings, so they may not have considered it
yet
… 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
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
Jake: Hope to do this
for game delivery, also smart TV devices for some specific content
owners
… 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
… You can defeat it but by making content look
identical, so everything has to be at the size the
largest
… People aren't willing to do that, as it increases
amount of traffic
… By saying we can't use multicast, you have to use
30x amount of traffic instead
… There's a problem of getting people to take
multicast seriously, which we go through with each group that looks
at it
… Let's find out where the real user threats are. I
don't want to diminish concerns
Kyle: The simple
argument to make it part of the web security model should be added
to the doc
… Some that are interested in this question would
be responsive to that
Jake: It's a point that
Lucas raised, reminiscent of DNS becoming a privacy considerations
thing over the last 8 years
… 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
… I agree it should go into the document. Would you
be able to raise an issue?
Kyle: Yes
Jake: Hoping to get
discussion going, not sure we'll be ready for a BoF by next
IETF
… In parallel, I'll be doing the Web Platform Tests
for WebTransport, to get together a strawman protocol
Dual Stack Relays
Jake: There's some test
traffic available
… 23.212.185.2 -> 232.1.1.1:5001
… 2600:14e0::2->[ff3e::8000:1]:5001
… I might set up VLC so there's something running
all the time
… The relay is theoretically running dual
stack
… 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
… 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
… Don't know why routing isn't behaving as expected
yet
… I'm hoping to have it running. Please let me know
if you'd like to work on this with me, to help
troubleshoot
… I have the relay discovery working, so lookup
with reverse IP of source address does find the relay
… I want to get onto the QUIC and WebTransport
part
… IPv6 is important, as I know people want it, but
it's not my core mission
Next steps
Jake: Kick off MSEC
discussion, start on WebTransport. Hope to have more for next
meeting
… Casey, were you interested in setting up
ingest?
Casey: Let's set a time to do that
Chris: Outcomes from the Second Screen meeting?
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
… 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
… Some who were there joined the TPAC Multicast CG
meeting. There's overlap with the privacy considerations in terms
of discoverability of local devices
… 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
… 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
… The second screen privacy considerations are
similar. It's not just multicast itself but also the local device
discovery
… He didn't talk about what the abuse is, but
there's an abundance of caution, principles of data
minimisation
… 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
… We're not solving the same problem, but some
commonality with privacy considerations