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

[Michael Richardson <[e-mail]>]

Roman Danyliw <[e-mail]> wrote:
    >> Roman Danyliw <[e-mail]> wrote:
    >> >> Generic interoperability is not expected.  Everything about the key
    >> >> management is essentially proprietary.
    >>
    >> > Thanks for this explanation.  The current -16 text even says that "key
    >> > management" is out of scope.
    >>
    >> > If no interoperability is expected, a lot more clarity is needed on the
    >> > currently documented security relevant mechanisms.  One interpretation
    >> > would be that the Mastroska container:
    >>
    >> > -- does not provide any interoperable security mechanisms to ensure
    >> > confidentiality, integrity or authenticity
    >>
    >> Correct.
    >> And as for Blowfish, 1DES, 3DES, etc. please recognize that these are
    >> *archives*, and they might have sat on a dusty spinning disk for 20 years.
    >> The goal is to be able to decode what's there, not necessarily to provide a
    >> mechanism useable into the future.

    > Understood.  My specific recommendation was ' -- 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.'  This guidance would be consist with the use case you
    > are suggesting of a Mastroska Reader finding old files, encrypted with
    > algorithms appropriate for their time.  The current text does not make
    > that distinction.

Okay, we could go further and say,
   "Compliant Matroska writers MUST NOT use encrypted blocks as Matroska does
   not include any key management or key agreement mechanisms"

I argued during WGLC that we mark the blocks as historical, but it's not
always clear to the software authors what that means.


    >> > -- provides a series of primitives and extension points on which
    >> > application developers could built security mechanisms
    >>
    >> could/have in the past, but didn't publish.
    >> These are files on disk.
    >> The decryption keys are either on post-its, or maybe involved some kind of
    >> online DRM system involving Hollywood.

    > If there are encrypted blobs on disk with unpublished DRM or encryption
    > schemes, how would this document help anyone decrypt the archives.

It won't, except to identify that there is stuff that is outside the
standard.

    > It
    > seems like some of the DRM-focused behavior is not explained on this
    > document.

A player that sees an encrypted block, needs to pop up a requestor for a key
(which could come from some other entity), or needs to invoke some plugin
behaviour that could return a key.  But that's all implementation, and way
beyond our scope.  At some remote future quantum computer state, maybe
Blowfish is sooo weak that it just cracks the key, as we see in sf all the time.

    >> As an *ARCHIVE* format, we need to document what might be out there.
    >> This is SMIME for video formats.

    > Section 23.2 explicitly suggests that this is not just a file archive format.

Correct, it's not a dead spec.
But there are many dead files out there which are not going to get converted.

WebM is a variation of it which is very actively used in many places like
youtube. (But, webm is a different subset than Matroska)

a) Encrypted blocks using Blowfish for DRM are probably not compatible with "live" streaming.
b) But, http://somearchive.example/blah.mkv could well be streaming some 20
   year old file.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide