Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT)

[Steve Lhomme <[e-mail]>]

On 2019-12-24 19:41, Benjamin Kaduk wrote:
> On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote:

>>> Section 11.1.16
>>>
>>>     Identically Recurring Elements SHOULD include a CRC-32 Element as a
>>>     Child Element; this is especially recommended when EBML is used for
>>>     long-term storage or transmission.  If a Parent Element contains more
>>>
>>> I'm not sure if the "long-term" is intended to also bind as "long-term
>>> transmission" (though I'm not sure what it would mean in that case).
>>> It's also not entirely clear what kinds of transmission would benefit
>>> from this, as reliable media presumably don't need redundancy for
>>> reliability, but unreliable media can't really be used to carry EBML
>>> without some framing requirements to know when elements start.
>>
>> Actually, as long as you have the "packets" in the right order you can
>> use the EBML stream. You can also use it if you're missing some
>> packets. The Checksum can help determine if the data are valid or not,
>> even if the underlying transport loses some bits. It could technically
>> be used as-is as protocol on top of IP, like TCP or UDP.
> 
> Huh, interesting.  Though I thought that UDP (and IP itself) didn't
> guarantee in-order delivery.

UDP and IP have no notion or order. But you can create protocols on top 
that do. Basically an EBML-based streaming format would just be:
[Packet Number][EBML element]
With EBML element smaller than 4000 or 1512 octets to fit nicely in 
Ethernet.
Anyway, that's definitely out of the scope of this document ;)
>>> Section 12
>>>
>>>     If a Master Element contains a CRC-32 Element that doesn't validate,
>>>     then the EBML Reader MAY ignore all contained data except for
>>>     Descendant Elements that contain their own valid CRC-32 Element.
>>>
>>> Ignoring only part of the known questionable content could have
>>> significant security considerations, if (e.g.) security-relevant
>>> restrictions are in the garbled part of the document but the sensitive
>>> content has a (valid) redundant CRC.
>>
>> That's why it's a MAY. If a Matroska Segment has a CRC and each frame
>> in it has a CRC. If the top CRC is invalid, we can still use some of
>> the frames that have a valid CRC. It's not a requirement but a
>> possibility.
> 
> I agree that it's an implementation choice for whether or not to do this,
> but please add some text in the Security Considerations that mentions the
> risk of handling incomplete-but-interdependent data when implementations
> choose to do this sort of thing.

I think it really depends on the dependency of the data at the semantic 
level. For example and EBML Element may define the type of data found in 
another EBML Element. If the type is damaged the interpretation of the 
data can create many kind of issues.

As for the CRC I think it's similar. It depends on what the CRC covers 
and the decision should probably be done at the semantic level, even 
with various options on how to handle the data.