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

[Eric Rescorla <[e-mail]>]

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=
[e-mail]> 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]:
> 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
>
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>