Original text:
4. <del> This document requires no actions from IANA. </del>  5.  This document introduces no new security issues.

Reviewer comments:
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?
NAME I am talking about privacy and pervasive monitoring now. See what you think on my next commit.
I did receive a private email from NAME pointing out that repeated encryption of the same content can lessen the protection of encryption against pervasive monitoring. I've added text about that, but also asked Glenn if he could provide a reference that I could include. Other than that, I think this PR is ready to merge. NAME or NAME 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 (URL)
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 (URL), the work of the PERC working group for RTP over UDP/TCP is another one (URL), 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: URL
I'm thinking I should take this one, especially with NAME 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 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).
NAME check this out: URL

Revised text:
4.  <ins> "Encrypted Media" has at least three meanings: Media encrypted at the application layer, typically using some sort of Digital Rights Management (DRM) system, and typically retaining this encryption "at rest", when it is stored at senders and receivers, Media encrypted by the sender at the transport layer, and remaining encrypted until it reaches the ultimate media consumer (in this document, referred to as "end-to-end media encryption"), and Media encrypted by the sender at the transport layer, and remaining encrypted until it reaches some intermediary that is _not_ the ultimate media consumer, but has credentials allowing descryption of the media content.  This intermediary may examine and even transform the media content in some way, before forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption") Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption may be used to prevent media steam manipulation or to protect manifests.  This document does not take a position on whether those goals are "valid" (whatever that might mean). In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end". Both "End-to-End" and "Hop-by-Hop" media encryption have implications for streaming operators. 4.1. 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. If traffic analysis is successful at identifying encrypted content and associating it with specific users, this breaks privacy as certainly as examining decrypted traffic. Because HTTPS has historically layered HTTP on top of TLS, which is in turn layered on top of TCP, intermediaries do have access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol I-D.ietf-quic-transport as its transport layer.  QUIC relies only on the TLS 1.3 initial handshake for key exchange I-D.ietf-quic-tls, and encrypts almost all transport parameters, with the exception of a few invariant fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the destination connection ID I-D.ietf-quic-invariants.  For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. 4.2. 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. There are a variety of ways to involve intermediaries, and some are much more intrusive than others. From a content provider's perspective, a number of considerations are in play.  The first question is likely whether the content provider intends that intermediaries are explicitly addressed from endpoints, or whether the content provider is willing to allow intermediaries to "intercept" streaming content transparently, with no awareness or permission from either endpoint. If a content provider does not actively work to avoid interception by intermediaries, the effect will be indistinguishable from "impersonation attacks", and endpoints cannot be assumed of any level of privacy. Assuming that a content provider does intend to allow intermediaries to participate in content streaming, and does intend to provide some level of privacy for endpoints, there are a number of possible tools, either already available or still being specified.  These include 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. "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. Secure Media Frames SFRAME - RFC8723 is closely tied to SRTP, and this close association impeded widespread deployment, because it could not be used for the most common media content delivery mechanisms.  A more recent proposal, Secure Media Frames SFRAME, also provides both hop-by-hop and end-to-end security guarantees, but can be used with other transport protocols beyond SRTP. If a content provider chooses not to involve intermediaries, this choice should be carefully considered.  As an example, if media manifests are encrypted end-to-end, network providers who had been able to lower offered quality and reduce on their networks will no longer be able to do that.  Some resources that might inform this consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- manageability (for HTTP/3 and QUIC). 4.3. "End-to-end" media encryption offers the potential of providing privacy for streaming media consumers, with the idea being that if an unauthorized intermediary can't decrypt streaming media, the intermediary can't use Deep Packet Inspection (DPI) to examine HTTP request and response headers and identify the media content being streamed. "End-to-end" media encryption became much more widespread in the years since RFC7258 was issued, which identified pervasive monitoring as a much greater threat than previously appreciated.  After the Snowden disclosures, many content providers made the decision to use HTTPS protection - HTTP over TLS - for most or all content being delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". </ins> 5. <ins> This document requires no actions from IANA. 6. </ins> This document introduces no new security issues.