Re: [Cellar] Roman Danyliw's Discuss on draft-ietf-cellar-matroska-18: (with DISCUSS and COMMENT)

[Steve Lhomme <[e-mail]>]

Hi,

Responses inline:

> On 24 Jul 2023, at 23:36, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-cellar-matroska-18: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (Updated ballot per -18)
> 
> [Per -16]
>> ** Section 5.1.4.1.31.9.  Table 26.  ContentEncAlgo Element.  Several insecure
>> algorithms are suggested as options (e.g., DES, 3DES).  Please add guidance
>> that:
>> 
>> -- Mastroska Writers MUST NOT use insecure ciphers (e.g., DES, 3DES) to create
>> "new content" (not sure of the appropriate word) either in this section or in
>> the Security Considerations
>> 
>> -- Add cautionary text that these algorithms are not secure
> 
> [Per -18]
> Thanks for adding the additional text into Table 26 – specifically, “[t]his
> value SHOULD be avoided” for DES, 3DES, and Blowfish.  This clarifying text
> begs clarity on when these could still be used.
> 
> There was a proposal on the mailing list for language against all use of
> encrypted block --
> https://mailarchive.ietf.org/arch/msg/cellar/CUXVLzNzSzGpz5GLro9f6BcpQQc/. 
> Should this be done?

We cannot disallow *all* encryption because it’s actively used by WebM. That would create inconsistencies between the two formats. And on the other side of things, Matroska benefits from a proven system that is known to work. The whole AES usage is borrowed from WebM.

> I proposed clarifying language against -16 to adopt an OpenPGP refresh
> (draft-ietf-openpgp-crypto-refresh) approach which distinguishes between
> disallowing the use of insecure ciphers for Writers, but allowing for the
> reading/processing archives previously made with these historic algorithms
> (that might have been appropriate at the time of creation).
> 
> NEW
> Mastroska Writers MUST NOT use insecure cryptographic algorithms to create new
> archives or streams, but Mastroska Readers MAY support these algorithms to read
> previously made archives or stream.

That sounds like a good generic rule. The security of cryptographic algorithms may vary over time (and computing power). So systems should adapt accordingly regardless of what the specs say at a given time.
I added your text to this Pull Request https://github.com/ietf-wg-cellar/matroska-specification/pull/797

> 
> [Per -16]
>> ** Section 14
>> 
>> ==[ snip ]==
>> This document does not specify any kind of standard for encrypting elements.
>> The issue of key scheduling, authorisation, and authentication are out of
>> scope. External entities have used these elements in proprietary ways. ==[
> snip > ]== > > Based on this text, it isn’t clear if Mastroska security
> properties are > supposed be interoperable solution for encrypted content
> across applications > (and how much is out of scope/left to proprietary
> implementations).  If > interoperability is not expected, please add language
> to that effect.  Some of > the feedback below might not be applicable if
> interoperability isn’t expected.
> 
> [Per -18] My position continues to be that strong language is needed to explain
> Section 14.
> 
> OLD
>   Encryption in Matroska is designed in a very generic style to allow
>   people to implement whatever form of encryption is best for them.  It
>   is possible to use the encryption framework in Matroska as a type of
>   DRM (Digital Rights Management).
> 
>   This document does not specify any kind of standard for encrypting
>   elements.  The issue of key scheduling, authorisation, and
>   authentication are out of scope.  External entities have used these
>   elements in proprietary ways.
> 
> NEW
> 
> This Matroska specification provides no interoperable solution for securing the
> data container with any assurances of confidentiality, integrity, authenticity,
> or to provide authorization.  The ContentEncryption Element (Section
> 5.1.4.1.31.8) and associated sub-fields (Section 5.1.4.1.31.9 – 12) are defined
> only for the benefit of implementers to construct their own propriety solution
> or as the basis for further standardization activities.  How to use these
> fields to secure a Matroska data container is out of scope.  As are any related
> issues such as key management and distribution.
> 
> Matroska Readers who encounter containers that use the fields defined in this
> section MUST rely on out-of-scope guidance to decode the associated content.

It sounds better indeed. I copied it to the Pull Request as well.

> 
> OLD
> 
>   The AES-CTR system, which corresponds to ContentEncAlgo = 5
>   (Section 5.1.4.1.31.9) and AESSettingsCipherMode = 1
>   (Section 5.1.4.1.31.12), is defined in the [WebM-Enc] document.
> 
> NEW
> 
> An example of an extension that builds upon these security-related fields in
> this specification is [WebM-Enc].  It uses AES-CTR, ContentEncAlgo = 5 (Section
> 5.1.4.1.31.9) and AESSettingsCipherMode = 1 (Section 5.1.4.1.31.12).

Also adjusted the paragraph to match your proposal.

> Additionally, please add caution to the Security Considerations to the effect
> of:
> 
> NEW
> 
> The Matroska specification provides no security assurances for the data
> container.  Fields related to adding security properties to the container
> described in Sections 5.1.4.1.31.8 – 12 do not form the basis of an
> interoperable solution.  Any implementation which builds on top of these fields
> will need to fully define their use and consider the security implications of
> the resulting design.

Isn’t this redundant with the first 2 paragraph you propose in Section 14 ? Also “security” seems a bit vague. For example the hashing of data provides some form of security of the data. The EBML checksum as well.
I left this proposal on the side for now.

> 
>> ** Section 5.1.4.1.31.*.  AES and associated modes (CTR and CBC) are named.
>> What is the key size?  Is it AES-128 (?) or -256. [WebM-Enc] references in
>> Section 14 suggests it is 128.  Please be explicit.
> 
> Please explicitly say that some of the algorithms described in Table 26 support
> different modes of operations and key sizes.  The specification of these
> parameters is required for a complete solution, but is out of scope of this
> document and left to the propriety implementations using them or subsequent
> profiles of this document.

Isn’t the key stored in ContentEncKeyID ? If so the size of the key is the size of the data in the element. It doesn’t need to be written somewhere else.
So if your system only supports AES-256 but ContentEncKeyID only has 16 octets (128 bits) then you don’t support it.

The WebM spec also doesn’t mention it but it’s implied by the elements necessary to support their encryption system.

> 
> [Per -16]
>> ** Section 5.1.4.1.31.10.  ContentEncKeyID Element.
>>     definition:  For public key algorithms this is the ID of the public
>>      key the the data was encrypted with.
>> 
>> The descriptive text is suggesting that the ID to a public key if public key
>> algorithms are described.  However, Table 26 only lists symmetric algorithms.
>> How is this key ID used?
> 
> I didn’t receive a response to this feedback.  Even recognizing that the
> security solution is out-of-scope, this text is inconsistent with existing text
> as described above.  Is the public key solution a KEK?

I had to lookup what a KEK is. I think the important naming here is ContentEncKeyID. It does not say it’s public or just a generic key. We could just remove the word “public” from the text.

> There is related text in Section 14 which references public keys which should
> be harmonized.  Specifically:
> 
>   For encryption systems sharing public/private keys, the creation of
>   the keys and the exchange of keys are not covered by this document.
>   They have to be handled by the system using Matroska.
> 
> [per -16]
>> ** Section 14.
>>   Encryption in Matroska is designed in a very generic style to allow
>>   people to implement whatever form of encryption is best for them.  It
>>   is possible to use the encryption framework in Matroska as a type of
>>   DRM (Digital Rights Management).
>> 
>> Enabling flexibility makes sense.  How is algorithm agility enabled?  How
> would > a new algorithm be added to Table 26?  In a protocol context, this
> might be > handled by an IANA registry enabling extensibility.

This is the same as for all the 28 enums in the format. A new document needs to be produced to add a new value. They are not values managed by a IANA registry.

Elements that are more subject to be often revised, like the codec ID, have their own registry.

> [per -18]
> I proposed removing this specific text above.  However, my original questions
> stands.  How is agility enabled?  Can a proprietary implementation insert a new
> code point?

Using values out of the values mentioned in the enum is out of the scope of the document. Some group of people may decide that they use a new value somewhere and be fine with it. But there’s no guarantee that value may not be used by us in the future. So if they want to be safe they should come forward with a document about that new value. In short: extending enums out of the IETF is at your own risk.

> 
> [per -16]
>> ** Please add cautionary language in the Security Considerations about what
>> explicitly would NOT be covered even if encryption was used.  For example,
>> Section 16 of RFC8794 notes that:
>> 
>> ==[ snip ]==
>> Even if the semantic layer offers any kind of encryption, EBML itself could
>> leak information at both the semantic layer (as declared via the DocType
>> Element) and within the EBML structure (the presence of EBML Elements can
>> be
>> derived even with an unknown semantic layer using a heuristic approach -- not
>> without errors, of course, but with a certain degree of confidence). ==[ snip
>> ]==
>> 
>> What are the specifics here on what “leaks”?
> 
> I didn’t see a response to this issue.

This seems like a question related to the wording in RFC8794 and not this document.
The text was added by Dave Rice in https://github.com/ietf-wg-cellar/ebml-specification/pull/54

I don’t really know what could leak here. And I can’t really think of anything that could leak either.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for documenting this important format in the IETF.
> 
> Thanks for addressing my COMMENT feedback and explaining the Matroska design to
> address some of my DISCUSS feedback.
> 
> 
> 
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar