search

ietf-wg-mops / draft-ietf-mops-streaming-opcons

drafts for the mops IETF working group
Other
6 stars 4 forks source link

E2E encryption #4

Closed acbegen closed 3 years ago

acbegen commented 4 years ago

This should be discussed in the following contexts: 1) Content owners feel more secure when their contents are encrypted at every level (at the transport/http level in addition to the application level, DRM, etc.). 2) E2E encryption is becoming more prevailing as the streaming service providers also do not want to be messed by the network service providers any more. a) Network service providers should not mess with manifests, requests, media, etc. This is unlawful for many reasons. b) Network service providers should rather co-operate with the streaming service providers to enhance the user experience as well as better utilize the network resources. See server and network assisted DASH, part 5 of the DASH standard (https://www.iso.org/standard/69079.html)

GrumpyOldTroll commented 4 years ago

I'm not sure the feelings of the content owners can be generalized cleanly, but I agree it might make sense to talk about the security (and privacy) characteristics of the available encryption approaches that can be applied at different layers, as well as the trends in the use of encryption. That seems like a good point.

I'm a little worried this is a can of worms that might be better as a separate document, because I think it gets quite complicated if we end up trying to explain the security properties, the threat models, and the challenges in guarding against the threat models, and far more so if that pulls us toward touching on anything potentially controversial.

But I agree there's probably something useful to say about encryption with regard to operational considerations for media streaming, and that it can likely be a useful section if we can keep the scope constrained.

agouaillard-cosmo commented 4 years ago

I believe there are many resources in terms of e2eme (m => media) that could be listed to give a good overview, without going too much int the details. DRM model for media, as used in conjunction with MPEG-DASH and HLS, and used by the W3C are one (https://www.w3.org/TR/2017/REC-encrypted-media-20170918/), the work of the PERC working group for RTP over UDP/TCP is another one (https://tools.ietf.org/html/draft-ietf-perc-double-12), QUIC is yet another one that would come naturally to mind first.

agouaillard commented 4 years ago

and recent work on e2ee for media over internet: IETF Frame Working group, and corresponding first draft: https://datatracker.ietf.org/doc/charter-ietf-sframe/

SpencerDawkins commented 3 years ago

I'm thinking I should take this one, especially with @agouaillard's suggestions. I'll probably downsize that specifically to streaming media, so leaving RTP-based techniques out (at least for now), but this looks super do-able.

agouaillard-cosmo commented 3 years ago

Hi spencer,

Note that SFrame, unlike it's predecessor PERC which is RTP specific, has been designed to be Media Transport agnostic as we wanted to be able to use RTP or e.g. QUIC. This design was made consciously, as threat models are always use case specific, and we wanted to extract the media encryption itself, which is common to the video conferencing use case and the streaming use case for example. One hope is that this could be used in conjunction to existing DRM facilities (KMS, ...) to extend DRM (in browsers) to the real-time use case, and also to cover the entire media path and not just the delivery part like DRM does today.

The SFrame draft itself describes only the media encryption, while other documents, for now external to the SFrame working group, describe key exchange with MLS in the video conferencing use case (Cisco), or the RTP use case specifically (Part of AVTCORE scope). It is being designed to be compatible with SVC codecs extension for RTP (AVTCORE), and new proposal for WebRTC's ingest signalling (WISH).

Let me know if you want some help in the matter, if only to point you to ongoing effort within IETF to get the big picture.

SpencerDawkins commented 3 years ago

This will heavily point to the impact on increased end-to-end encryption on network operators. RTCWeb (RFC 8825) has a section on this, as does QUIC Manageability.

Make sure we describe what happens if manifests are encrypted - operators that lower the offered quality to reduce impact on their networks can't do that any more. Also true for analytics/feedback hijacking. Find and reference a public discussion (Netflix, someone in MOPS may be able to provide this).

acbegen commented 3 years ago

@SpencerDawkins check this out: http://library.usc.edu.ph/ACM/SIGSAC%202017/codaspy/p361.pdf