Meeting reminder and call to action

Hi multicast cg,

Tomorrow morning's meeting is about 8.5 hours from this message,
I hope to see you there.  The meeting coordinates are here:

One other item:

I sent a message to secdispatch requesting a slot to discuss our
proposed multicast security model:

An unusually lively discussion has already been opened, with the
TLS 1.3 author suggesting this isn't ready due to insufficient
consensus there's something worth working on in the security

If you're willing and able, a brief note of support sent to secdispatch
might encourage some of them to consider this effort worthwhile,
whereas if I can't demonstrate some support I'm worried they won't
want to give it a venue, as that's an answer we've seen before for
multicast security work.

If you haven't participated in the IETF before, it might be useful
to take a look at the secdispatch charter:

And also at the Tao of the IETF.  I guess the section 4 on
Working Groups is the main thing, but earlier sections can also
provide some important context if you have questions:

It should work to just send a message to with
"Re: [Secdispatch] Requesting agenda time for draft-krose-multicast-security"
as the subject, I think.

Do please be respectful and brief if you write, I'm mainly looking
to establish that there's a real need for this capability from
some real web users and developers (as well as ISPs and content
providers), and most of the discussion of the security considerations
doc itself should probably go into a different venue, ideally,
regardless of the messages on the thread so far.

Best regards,

On 10-26, 5:17 PM, "Holland, Jake" <> wrote:

Hi secdispatch,

I hope some of you had a chance to take a look at the document
Kyle sent about the security model for multicast for web traffic[0]:

I'm requesting a slot to talk about it for IETF 112, and hoping we
can get it dispatched to an appropriate venue.

Some background:

We've been doing some work on making multicast viable for web
traffic.  I'm chairing a W3C community group chartered to incubate
it[1].  We have a straw-man API[2] with a demo implementation[3]
(without the proposed authentication scheme[4] implemented yet)
that can support an app ported to wasm playing video[5].  As the
charter states, we're aiming to get into webtransport first in a
way functionally similar to the demo (server-to-client datagrams),
and into other APIs like fetch/xhr, the h5 download attribute, and
webrtc afterwards.

We had hoped to do some further experimentation behind a command-
line flag, but my understanding of the key feedback we got when we
suggested this to chromium[6] was that we need a better security
model with wider consensus before we can do anything like this.
In particular, proposals for web traffic that have different
security properties from TLS will need robust review.

So we're looking for the right venue (and reviewers!) to establish
a well-considered IETF consensus on what it takes to make multicast
safe enough for the modern internet, particularly including web

We're hoping the final version of this doc will serve as the
foundation for guiding any necessary extensions to the appropriate
protocols, in much the same role that RFC 8826 played for WebRTC.

Thanks and regards,

PS:  Please note that it may also be appropriate and valuable,
depending on the answer, to move draft-ietf-mboned-ambi to the same
venue, as some of the discussion in mboned made me suspect it may
not be the right home for discussion of its security properties.







Secdispatch mailing list

Received on Wednesday, 27 October 2021 06:21:14 UTC