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

[Benjamin Kaduk <[e-mail]>]

On Fri, Dec 27, 2019 at 10:17:58AM +0100, Steve Lhomme wrote:
> On 2019-12-24 19:41, Benjamin Kaduk wrote:
> > On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote:
> 
> >>> 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.

I entirely agree that it depneds on the semantics of the particular data in
question.  That said, even if it only would happen for a small fraction of
actual usage, typically we still see fit to document the existence of the
risk for the affected cases, in the security considerations.

-Ben