Content "protection" and "encryption"

[kixelated]

Heh sorry about ragging on the typos.

The catalog and media object payloads MAY be encrypted. Common Encryption with 'cbcs' mode (AES CBC with pattern encryption) is the RECOMMENDED encryption method.

I know many people at IETF will take offense at the "RECOMMENDED encryption method". If you're just trying to obfuscate content with DRM (content protection), something like Common Encryption with AES CBC is fine (I believe only the mdat is encrypted). If you're actually trying to protect content against an adversary, then want to encrypt the entire object payload with an AEAD.

I don't think this section is necessary since we're delegating to CMAF anyway.

[wilaw]

I don't think this section is necessary since we're delegating to CMAF anyway.

One of the main interop problems with CMAF is that it supports multiple incompatible CENC options. I was hoping that MoQ could avoid these problems by mandating a single DRM scheme from the start. Is AEAD CMAF compliant? I don't think it is. We would therefore have a dilemma - keep the convenience of CMAF(CENC) , or fork it to add in the newer AEAD?

[vitaly-castLabs]

Neither CENC nor mainstream DRM systems use AEAD ciphers since there's no need for media data authentication. The whole industry converged to 128-bit AES CBC as described in the CENC spec (cbcs), so it would make a lot of sense to lock it down to keep straying vendors in check (HW-secure PlayReady on my Windows laptop only supports 'cenc' scheme, go figure). The whole section might well be "Refer to the CMAF spec, but only 'cbcs' is allowed".

The encryption scenario is very different and shouldn't be conflated with DRM. "Encryption activists" will definitely want AEAD, 256-bit AES, probably with a variety of ciphers to chose from (GCM, ChaCha20), no CENC-style "clear ranges", etc