Skip to main content

IETF Last Call Review of draft-ietf-cellar-tags-19
review-ietf-cellar-tags-19-secdir-lc-sethi-2025-10-12-00

Request Review of draft-ietf-cellar-tags
Requested revision No specific revision (document currently at 23)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-10-13
Requested 2025-09-29
Authors Steve Lhomme , Moritz Bunkus, Dave Rice
I-D last updated 2026-03-11 (Latest revision 2026-02-26)
Completed reviews Genart IETF Last Call review of -19 by Ines Robles (diff)
Secdir IETF Last Call review of -19 by Mohit Sethi (diff)
Artart IETF Last Call review of -19 by Sean Turner (diff)
Artart Telechat review of -20 by Sean Turner (diff)
Assignment Reviewer Mohit Sethi
State Completed
Request IETF Last Call review on draft-ietf-cellar-tags by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/M6YJdmJfJHKTGjieZMetGPC4530
Reviewed revision 19 (document currently at 23)
Result Ready
Completed 2025-10-12
review-ietf-cellar-tags-19-secdir-lc-sethi-2025-10-12-00
Reviewer: Mohit Sethi
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last-call
comments.

This document defines multimedia container tags for Matroska files, which carry
multimedia data. Standardizing these tags allows applications to process and
act on them uniformly. This draft is certainly not in my area of expertise but
it was interesting to read and learn about something new.

The primary security concerns stem from the parsing of various tag fields,
which is an inherent risk in any scenario involving the processing of external
structured data. Without proper input validation and robust error handling,
processing malformed data could lead to vulnerabilities. For this, the draft
primarily points to the security considerations of RFC 9559 (Matroska Media
Container Format Specification) and RFC 8794 (Extensible Binary Meta Language).
The draft also correctly notes that nesting of tags could be exploited with
very deep nesting to exhaust memory of the entity parsing the tag fields.

It is not common for drafts to justify the rationale for standardizing as is
done in section 3.1 of this draft. I like it.

Preventing multiple items from being stored as a single list is not the most
storage optimal? Perhaps document the justification for enforcing multiple
SimpleTags with the different values instead of a list?