Draft: draft-ietf-mops-streaming-opcons

Commentary: I think the separation between hop - by - hop vs. transport is useful . Do we need to say something about privacy and/or pervasive monitoring and point out that end - to - end encryption has one set of properties and hop - by - hop media encryption has a different set of properties ? 
 I am talking about privacy and pervasive monitoring now . See what you think on my next commit . 
 I did receive a private email from pointing out that repeated encryption of the same content can lessen the protection of encryption against pervasive monitoring . I 've text about that , but also asked  if he could provide a reference that I could include . Other than that , I think this PR is ready to merge . or any objections ? 
 LGTM , go for it 
 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 ( ) 
 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 . 
 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 ( ) , the work of the PERC working group for RTP over UDP / TCP is another one ( ) , QUIC is yet another one that would come naturally to mind first . 
 and recent work on e2ee for media over internet : IETF Frame Working group , and corresponding first draft : 
 I 'm thinking I should take this one , especially with 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 . 
 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 . 
 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 ca n'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 ) . 
 check this out :
Paragraph (version B):
The use of strong encryption does provide confidentiality for
encrypted streaming media, from the sender to either an intermediary
or the ultimate media consumer, and this does prevent Deep Packet
Inspection by any intermediary that does not possess credentials
allowing decryption.  However, even encrypted content streams may be
vulnerable to traffic analysis.  An intermediary that can identify an
encrypted media stream without decrypting it, may be able to
"fingerprint" the encrypted media stream of known content, and then
match the targeted media stream against the fingerprints of known
content.  This protection can be lessened if a media provider is
repeatedly encrypting the same content. codaspy is an example of what
is possible when identifying HTTPS-protected videos over TCP
transport, based either on the length of entire resources being
transferred, or on characteristic packet patterns at the beginning of
a resource being transferred.
Paragraph (version B):
Although the IETF has put considerable emphasis on end-to-end
streaming media encryption, there are still important use cases that
require the insertion of intermediaries.
Paragraph (version B):
There are a variety of ways to involve intermediaries, and some are
much more intrusive than others.
Paragraph (version B):
Server And Network assisted DASH DASH-SAND - this specification
introduces explicit messaging between DASH clients and network
elements or between various network elements for the purpose of
improving the efficiency of streaming sessions by providing
information about real-time operational characteristics of
networks, servers, proxies, caches, CDNs, as well as DASH client's
performance and status.
Paragraph (version B):
"Double Encryption Procedures for the Secure Real-Time Transport
Protocol (SRTP)" RFC8723 - this specification provides a
cryptographic transform for the Secure Real-time Transport
Protocol that provides both hop-by-hop and end-to-end security
guarantees.