Re: [Cellar] Security considerations: recursive elements

[Michael Bradshaw <[e-mail]>]

On Wed, Jan 17, 2018 at 11:42 PM, Jerome Martinez <[e-mail]>
wrote:
>
> I missed the case of recursive elements, specified in EBML.
> for a security section, I don't think that talking about a parser is right


The current EBML specification's Security Consideration section contains a
bulleted list for "Attacks on an EBML Reader" (where an "EBML Reader" is
explicitly defined as a "data parser[...]"). So if we shouldn't be talking
about security considerations for parsers, then that whole bulleted list
should be removed (which I'm opposed to doing). Perhaps I've misunderstood
your point here, though.

I am more in favor of  something like "it is possible to have unlimited
> recursion, potential source of denial of service attacks" in security
> section and
> "An implementation may set limits on the maximum depth of nesting" in a
> parser section (similar to JSON RFC).


My apologies if my previous communications have been unclear, but this is
actually what I'm trying to advocate for, so I think we might agree more
than we realize. While I have been suggesting including minimum/maximum
levels, I think that using something like you've written here (and
completely omitting minimum/maximums) would still be a great improvement.

I do think that also including some kind of minimum/maximum levels could be
useful. I also think that if we do have them, they should use SHOULD/MAY
language instead of MUST. Using SHOULD/MAY would give guidance to
implementors on how they can maximize interoperability while still allowing
them total freedom (the implementation would still be conforming to the
spec even if it went against a SHOULD/MAY guidance).

We don't talk anymore about security, and confidence depends on the
> underlying document e.g. for my EBML document x, I may need only 1 level
> beside the EBML header and it is fine with that, no need of more.
> So:
> - A minimum should not be in Security section (it is not about security)
>

I agree that minimum or even maximum limits should not be placed in the
security section. They belong elsewhere in the Matroska specification
(exactly which section, I don't know). Sorry for not stating this more
clearly in my original email.

- A minimum depends on the goal of the parser, e.g. a parser just checking
> top level element size and CRC for checking a file transfer is fine does
> not need more than 2 levels. Not all tools are video players.


I'm not advocating for HOW the parsers should handle deep recursion (I
probably shouldn't have used the language "abort the parse" in my original
email; it was just meant to be a starting point for the conversation).
Handling it by skipping it is fine. If a particular element is not needed
for the goals of the application, the parser should certainly feel at
liberty to skip over it.

But a player may just ignore any chapter and tag elements and still play
> fine the file.


Yes, the encoded media data can still be parsed/decoded and the media can
still be played. But part of playing a video is showing to the user the
chapter and tag information to the video. If the player ignores the chapter
or tag elements, then the playback experience is incomplete. Not all
players utilize the chapter and tag elements, but those that do will likely
have some kind of upper limit on the level of recursion they can
meaningfully handle.