Re: [Cellar] shepherd review of Matroska: part 1

[Steve Lhomme <[e-mail]>]

On 2022-06-12 10:01, Steve Lhomme wrote:
>> } 5.1.4.1.34.9. ContentEncAlgo Element
>> questions will be asked about 1DES, and 3DES.
>> 1) We need a note about how legacy files might be encrypted, and we need
>>     those definitions for history.

AFAIK Matroska files are not encrypted. WebM on the other hand is very 
common. But we're not making the WebM spec. Content Compression which is 
parallel to this is however common.

In WebM it also depends on the codec what kind of information is 
actually encrypted. The frame headers are usually not encrypted so they 
can be parsed without dealing with encryption. Only the actual content 
part is encrypted.

We do not have this kind of granularity in Matroska. The 
ContentEncodingScope only mentions encrypting the content of the Block. 
But I think in real life that's still to broad.

There's a specific WebM page about which (single) encryption it supports
https://www.webmproject.org/docs/webm-encryption/
They actually have "partitions" within the Block. While it is compatible 
with ContentEncodingScope=1 (All frame content) it is still not enough 
to know where the partitions stand and how to deal with them. They also 
allow some frames to be encrypted and others not.

IMO that should be the way to do it. Matroska provides the fields to 
store your encryption information, but the way they are interpreted is 
not really defined in Matroska. In the case of WebM, the AES-CTR 
(AESSettingsCipherMode=1) really tells the whole story of how the 
encrypted data fill the Block.

This is the only encryption known in the wild for Matroska/WebM. All the 
rest is under defined.

>> 2) Questions will be asked about how the keys were created.
>>     I haven't read the Security Considerations, but it needs to say 
>> something.

It's (currently) not mentioned but there is an "Encryption" section. It 
doesn't cover the key creation/exchange.

>> 3) We should probably have a suggestion on how encryption keys are
>>     represented in text.
>>     Consider one system that takes things in hex, and another that
>>     uses strings, and that all hex values are valid strings.

IMO it's not relevant in our case. The keys are stored in binary format 
(ContentEncodings\ContentEncoding\ContentEncryption\ContentEncKeyID), so 
human readable formats are for usage outside of Matroska.

> I'll try to come up with something. Although I'm not too familiar with 
> this part. It is however used in WebM.

The result is 
https://github.com/ietf-wg-cellar/matroska-specification/pull/630