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

[Roman Danyliw <[e-mail]>]

Hi Steve!

Thanks for all your iteration on the document to respond to my feedback.  I just cleared my ballot per the new merged text in -19.

Thanks,
Roman

From: Steve Lhomme <[e-mail]>
Sent: Saturday, August 12, 2023 7:55 AM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; Codec Encoding for LossLess Archiving and Realtime transmission <[e-mail]>; Michael Richardson <[e-mail]>
Subject: Re: [Cellar] Roman Danyliw's Discuss on draft-ietf-cellar-matroska-18: (with DISCUSS and COMMENT)

Hi everyone,

The Pull Request has been merged with all the changes, plus additional wording fixes.
This is now in version 19 of the draft: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/19/

Steve


On 5 Aug 2023, at 13:09, Steve Lhomme <[e-mail]<mailto:[e-mail]>> wrote:

Hi Roman,


On 30 Jul 2023, at 14:41, Steve Lhomme <[e-mail]<mailto:[e-mail]>> wrote:

[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.

A bit more on this. I did my own research and found out about Key IDs in the Encrypted Media Extension [1]. As the name suggests, it’s not an actual key but an ID the host app has to interpret.
However for asymmetric encryption algorithms, ie that use a public key, it may usually be preferred to share the public key rather than an ID. For symmetric algorithms the key must not be in the file, that’s why it’s using an ID that both sides must understand.

None of the algorithms in ContentEncAlgo are asymmetric ones. So for now we don’t support asymmetric encryption. If that ever happens we’ll need to define where the public key goes. IMO it could be ContentEncKeyID if the key is not in the file. And it should be a different element if the key is in the file.

** 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.

OK, now I understand we do not put any actual key in the Matroska files. So we can’t deduce the key size from our element.

I added your text suggestion in the Pull Request [2]

[1] https://www.w3.org/TR/encrypted-media/
[2] https://github.com/ietf-wg-cellar/matroska-specification/pull/797