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

From: "Holland, Jake" <[email-masked]>
Date: Wed, 27 Oct 2021 00:16:49 +0000

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]:
https://datatracker.ietf.org/doc/html/draft-krose-multicast-security

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
traffic.

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,
Jake

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.

[0] https://mailarchive.ietf.org/arch/msg/secdispatch/LRMHRKiHfk3vgV43KRbG31x-y4I/
[1] https://www.w3.org/community/multicast/
[2] https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md 
[3] https://github.com/GrumpyOldTroll/chromium_fork
[4] https://datatracker.ietf.org/doc/html/draft-ietf-mboned-ambi
[5] https://www.w3.org/2021/10/TPAC/demos/multicast.html
[6] https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/_Syfhri7AAAJ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Oct 2021 19:00:16 -0700

I have reviewed this document. While I have some technical comments
below, my bigger comment is that this is the wrong place to start.

The right place to start is what the application use cases are and
whether there is demand. Once that is done, we can discuss the
security properties and whether they are feasible. You make the
comparison to 8826, but that was written *after* there was agreement
that we wanted to do something like WebRTC. IOW, this belongs in
DISPATCH.

S 3.2.

   The Web security model requires that content be authenticated
   cryptographically.  In the context of unicast transport security,
   authentication means that content is known to have originated from
   the trusted peer, something that is typically enforced via a
   cryptographic authentication tag:

This is true, but I think misses an important property of Web
authentication, which is the binding between the request and
the response. I.e., the property is not just that the message
came from the peer but also that it came in response to a given
request.

Viewed in this context, this text is misleading:

   Asymmetric verification of content delivered through multicast is
   conceptually identical to the unicast case, owing to the asymmetry of
   access to the signing key; but the symmetric case does not directly
   apply given that multiple receivers need access to the same key used
   for both signing and verification, which in a naive implementation
   opens up the possibility of forgery by a receiver on-path or with the
   ability to spoof the source.

S 3.3.

   A baseline for multicast transport integrity that makes sense within
   the Web security model requires that we first define the minimally
   acceptable integrity requirements for data that may be presented to a
   user or otherwise input to the browser's trusted computing base.  We
   propose that the proper minimal standard given the variety of
   potential use cases, including many that have no need for reliable or
   in-order delivery, is to require protection against replay,
   injection, and modification and the ability to detect deletion, loss,
   or reordering.  This standard will necessarily constrain conformant
   application-layer protocol design, just as the Web security model
   adds constraints to vanilla TCP.

This also seems like the wrong layer of abstraction, as it talks
about comsec properties, but those aren't the ones that the Web
depends on. i would start from the top and ask what it is the
Web wants, not what it is TLS provides.

S 3.4.1.
   In contrast to (say) unicast TLS, on-path monitoring can trivially
   prove that identical content was delivered to multiple receivers,
   irrespective of payload encryption.  Furthermore, since those
   receivers all require the same keying material to decrypt the
   received payload, a compromise of any single receiver's device
   exposes decryption keys, and therefore the plaintext content, to the
   attacker.

This isn't just about compromise by an attacker but also attacks
by other legitimate receivers. The Web doesn't currently allow that
but you would introduce that.

-Ekr

On Tue, Oct 26, 2021 at 5:17 PM Holland, Jake <jholland=
[email-masked]> wrote:

> [0]
> https://mailarchive.ietf.org/arch/msg/secdispatch/LRMHRKiHfk3vgV43KRbG31x-y4I/
> [2]
> https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md
> [6]
> https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/_Syfhri7AAAJ
>
>
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 27 Oct 2021 05:18:56 +0000

Hi Eric,

Thanks for the review and comments!

I have a few responses:

From: Eric Rescorla <[email-masked]>
Date: Tue,2021-10-26 at 7:01 PM

> that we wanted to do something like WebRTC. IOW, this belongs in

I guess this had not occurred to me.

I see why this would be a necessary step for WebRTC, but for multicast
the problem is not application use cases (we don't propose to add any),
but rather scalability use cases, and here I believe the numbers
speak for themselves.

I've published a few simple analyses on this subject before.  Sorry
I didn't include them in the initial message, I thought the general
nature of the issue was reasonably well-known from the prior attempts
to get multicast working, but in retrospect maybe I should have
included some.  Here are a few with reasonably modern numbers:

1. Explainer for the first draft API proposal:
https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md#scaling-problem-examples

2. Similar numbers here:
https://blog.apnic.net/2020/07/28/why-inter-domain-multicast-now-makes-sense/

3. A bar-bof at IETF 111, where I covered some of the effects and
impact of peak internet days:
https://www.youtube.com/watch?v=vKHdTrhQHLo
slides: https://trac.ietf.org/trac/ietf/meeting/attachment/wiki/111sidemeetings/slides-ietf111-side-meeting-web-multicast.pdf

There's probably a few others I can dig up if you'd like more, but
I think that should give the gist.

Additionally, there's several adopted drafts in mboned, where it
seems there's already consensus on the long-overdue need to
deploy some usable multicast delivery for scalability reasons.

While I do think there's good evidence of a scalability problem
with the current mostly-unicast-only internet and pre-existing
IETF consensus that it's worth addressing, I do think that the 
work so far lacks sufficient security review to take it further,
which is why I'm reaching out now to secdispatch.

I don't believe this is an ART area issue, since what I'm aiming
for is to keep roughly the same app objectives as today, but to
deliver content more efficiently when there's high concurrency
in the data to be delivered in response to user demand.

> came from the peer but also that it came in response to a given

Thanks, that's an excellent point and I agree the text should be
updated to reflect this property.  I opened an issue to track it:
https://github.com/squarooticus/draft-krose-multicast-security/issues/12

This is exactly the kind of feedback I hoped to get by bringing
it here, much obliged.

>    ability to spoof the source.

If I understand correctly, if we can provide the appropriate text
about binding to the request, then this would no longer be misleading?

Although there remain some potential differences, I think there are
some analogous cases in webtransport and h2 server push, for example,
where it's possible for a receiver to get some things that it's not
interested in processing, but nevertheless are associated with a
resource that was actually requested.  Maybe there's some good text
on those subjects we could adapt here to refine this point, if it's
necessary?

> Web wants, not what it is TLS provides.

I think I've gotten an answer to this question, for example here:
https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/GYFqpys3GwAJ

"The web security community has worked for more than a decade to get
us to this good place with transport security. I don't think we should
experiment with a new form of mixed content. The security properties
of TLS are the minimum baseline going forward."

(I've heard this phrased very similarly in several other in-person
conversations.)

Hence, we try here to speak to the security properties of TLS, since
they've been demonstrated as satisfactory to the best of our current
knowledge for web traffic.

I don't know a better answer to the question of what security
properties the web wants.  If you can point me to one I'd be
grateful, but I thought this was enough to work with.

> but you would introduce that.

This is the key reason we propose to decouple the authentication
functionality from the encryption functionality, so that we avoid
introducing integrity-based attacks by anyone who's not a legitimate
sender (including legitimate receivers).

For decryption-based attacks (e.g. pervasive monitoring via discovery
of the contents being transported), I think this is one of the key
areas where we'd like to get more eyeballs on the problem, and
articulate the threat models and the scope of the issues better than
they've yet been articulated.

Over and over, I see the hard requirement for encryption justified by
a threat model that includes exposing personal information such as
bank account info.  While I agree this is an important threat model
that justifies strong encryption in many situations, it's not clear
that it applies quite the same way to a video frame from the Superbowl,
where we'd be particularly interested in leveraging the scaling of
multicast.

Teasing apart and pinning down that difference to the satisfaction of
the IETF's best security expertise is one of the most important things
I'd like to accomplish by getting the right eyeballs on this doc.  I
think we have a start at this in the Privacy section, but to me this
seems like one of the most complex questions in this space, and it
seems likely to me that some people in the IETF security area will
have valuable insights that I hope can be articulated and captured.

--

Multicast is of course in use widely today already, with ISPs directly
providing content to their customers, and thereby gaining intimate
knowledge of exactly what content (that they provide) is delivered to
which households, often with a captive audience who doesn't have any
alternatives. 

One key question that I wish we had articulated better in the first
version of this doc is whether using multicast to move some of that
content to an equally-scalable but externally sourced provider (with
perhaps a wider choice of providers for the viewer) who is NOT the
ISP would improve matters, keep them the same, or make them worse
(and which specific matters, with what kinds of tradeoffs if the
answer is mixed).  I'm hopeful that some continued focus on the
questions in this doc will bring some insights to light.

But I guess the higher-level issue is that if the right answer really
is that multicast fundamentally cannot be made compatible with web
traffic because of its security constraints, then I want to know that
as quickly as possible (and if so whether a different approach could
reach the same kind of scalability without the same impediments).

But as it stands, I don't believe it's true, I just think it hasn't
been properly hammered out yet.

Which brings it back to why I've requested the attention of the
security area to this topic and this draft.

> -Ekr

Thanks again, I very much appreciate the review and we'll add you
to the acknowledgements in the next version.

I hope I've addressed the points raised here and made the case that
this doc is appropriate for secdispatch, but if anyone has further
objections or thinks I missed an important point here, please let
me know and I'll try to do better.

Best regards,
Jake

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Oct 2021 11:25:24 -0700

> but rather scalability use cases, and here I believe the numbers

I think I'm asking a different question: specifically "What web sites and/or
browsers are interested in deploying this technology and for what uses"?

> about binding to the request, then this would no longer be misleading?

I don't know. I'd need to see the text.

> on those subjects we could adapt here to refine this point, if it's

These are still tied to the connection.

> knowledge for web traffic.

Well, ISTM that you are clearly not delivering the same properties
as TLS, so if that's the benchmark, I don't see how this can make
progress.

> where we'd be particularly interested in leveraging the scaling of

This seems like a regression to me. Which content people are consuming
should *also* be confidential, even if multiple people can see that content.
That's a property they largely have with respect to the network now, and we
should be looking to extend it, not to regress it.

-Ekr

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 29 Oct 2021 20:03:53 +0000

From: Eric Rescorla <[email-masked]>
Date: Thu,2021-10-28 at 11:26 AM

> browsers are interested in deploying this technology and for what uses"?

We're interested in using this with a wide set of our customer's
websites, mainly for video that is popular and/or live.  Also for
popular file downloads and software updates.

I can't really disclose all our partner discussions in this public
forum, but in general people are eager to get the discount this would
come with if it works and doesn't hurt performance (and more so if it
helps performance), especially if it doesn't need big changes in their
player implementations.

I sent out a few invitations to comment on this thread, maybe some of
them or some other interested people will be willing to chime in.

I'm not sure what the filtering rules for this list are, because one
(DAZN) did respond so far that I got on private mail, but I didn't see
the message come through on the list.  Also BBC has publicly expressed
support for work in this direction before.

I think no browser will take this until the security model is better
articulated, and so of course none have committed, since consensus on a
doc like this is a blocker.

But the chromium discussion wasn't "go away, this will never work", but
rather "this needs encryption at least--even if multiple people can
decode it, those without a key cannot, so it provides some improvement
over non-encrypted".  That was an excellent point that comes with some
complexity, some of which we're trying to get written down here.  That's
not the same as "yes we'll ship it", but it's as positive as could be
hoped for at this stage.

The W3C discussion is also getting under way, this aligns well with some
sustainability initiatives that are ramping up.  The Web Networks IG at
their TPAC meeting said they'll be adding it as a use case and
supporting and encouraging the work.  I've put in a request to add it to
the webtransport use cases that's still to be discussed.

There's good reason to believe that at least one good use case can be
hashed out, so unless it turns out to be impossible to do this safely on
close examination, we can expect eventually all the major browsers
outside of things like Tor will be interested.

But of course, user safety comes first, hence the urgent need to pin
down the right security model.  It's all early stages, but also entirely
dependent on getting consensus on the right constraints under which to
operate a service like this.

> as TLS, so if that's the benchmark, I don't see how this can make

Well, "exactly TLS" is slightly off, as evidenced for instance by the
support for DTLS, which relaxes a minimal set of TLS's guarantees to
match the nature of its underlying transport and the use cases for which
it's applicable.

Multicast would be a different kind of transport with some different
properties that might put constraints on use, so it's important to
articulate what those constraints are and get the proper expert review
to avoid as many problems as we can up front.

> should be looking to extend it, not to regress it.

Multicast in particular also comes with a removal of an individualized
destination IP address and port, which makes it much harder to tie the
content to the individual who's consuming it, from an on-path observer's
point of view.  Is it really the "content being consumed" that has to be
confidential, or the knowledge that a specific individual is watching
it?

There's also some more holistic considerations.  The vast improvement to
efficiency and scale that is possible here can be expected to improve
end user costs and provider choice, and for many this might be a highly
desirable tradeoff for a lot of cases.  The real question is to figure
out in what situations it's ok.

It's hard to believe the answer is 'never' when the alternative is to
send that content through a TV station and have their provider, the same
one providing the internet services in most cases, know all about
exactly where it's going, because the delivery *does not scale* to web
delivery without multicast and can't take advantage of the benefits of
web security anyway.

Service providers need to understand the issues and make the right
tradeoffs, but performance is one of them, and in some situations it's
not worth a factor of 10k on efficiency to maintain a security property
that's not very important to the safety of the users who are using that
particular service, particularly when the viable alternatives, which we
know from history they'll willingly use en masse, are as bad or worse.

I guess we can and probably should rathole on this for some time, and it
would be good to get more voices in the discussion.  That's why I'm
asking secdispatch to consider this work and advise us on the best
venue.

Best,
Jake

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 29 Oct 2021 21:42:19 +0100

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/

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Oct 2021 08:00:00 -0700

> them or some other interested people will be willing to chime in.

OK, well, I think some significant showing of interest from other people
is a prerequisite for serious consideration of this idea.

> doc like this is a blocker.

Well, I agree about commitment, but there have been plenty of efforts
(WebRTC, QUIC, MLS, etc.) with far more active levels of enthusiasm
from browsers than this seems to have

> not the same as "yes we'll ship it", but it's as positive as could be

I think you're reading this as a greater showing of interest than I do,
but I guess Chris Palmer can speak for himself. Or maybe David
Schinazi or David Benjamin would like to clarify Chrome's thinking.

> match the nature of its underlying transport and the use cases for which

Well, browsers don't support DTLS in the sense that they support
TLS. What they support is a new API surface that is designed to
serve a different set of application use cases from content delivery,
i.e., WebRTC.

> point of view.

I'm not sure about "much harder". If you can observe the routing
information you know a lot.

 -Ekr