Re: [Secdispatch] Requesting agenda time for draft-krose-multicast-security

[Lucas Pardue <[e-mail]>]

Hello,

This is a very good discussion and I can't possibly hope to address the
fine points that have been made by the different sides.

What I will add as a point of reference is that a while ago when penning
draft-pardue-quic-http-mcast, me, co-authors and associates tried hard to
think about and capture the security and privacy aspects of using multicast
for delivery of HTTP [1]. In the meantime, Jake, Kyle and co. have
continued to work on addressing some of the questions; AMBI for integrity
at the packets-level for example.

The interesting higher-level question I'm getting from this discussion (and
the ones in other venues) is whether there is any form of "secure
multicast" can address the sorts of confidentiality/privacy questions that
EKR raises. Work on secure multicast is not brand new, there was the MSEC
WG [2] who produced 18 documents on the topic. However, the design choices
for draft-pardue-quic-http-mcast imagined a world where there is not
IP-layer security, and so security needed to be provided by either the
transport or the application. As noted in the document, the ability for
someone with the key to produce QUIC packets weakens those assurances, so
additional asymmetric protections are added at the HTTP layer (digests and
signatures). I'm not suggesting it solved all the problems, but it was
demonstrably more secure that other multicast-based delivery methods that I
am aware of.

As Jake indicated, and as I can't speak for because I'm no longer close to
the domain, multicast is widely used in several domains where real people
at home consume it. That's typically done as part of a service that they
pay for and they are likely to have no idea that the provider is doing
this. If there's a problem with privacy of multicast-delivered services, we
are in the thick of it. This bears some striking resemblence to DNS of
yonder, where there was no notion in the general populace of more secure
DNS or DNS provider agility. It would be nice to create a world where
over-the-top IP multicast services are just as widespread as unicast ones
(where networks allow that to be feasible) and answering the
security/privacy question is important to getting there.

Cheers,
Lucas



[1] -
https://datatracker.ietf.org/doc/html/draft-pardue-quic-http-mcast-09#section-11
[2] - https://datatracker.ietf.org/wg/msec/about/