Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-23 -- here: active content

[Stephan Wenger <[e-mail]>]

Hi all,
This is the companion email related to the one point of Julien's secdir
review where we are a bit reluctant to make a non-editorial change.

>>    Decoders MUST exercise caution with respect to the handling of
>>    reserved NAL unit types and reserved SEI messages, particularly if
>>    they contain active elements, and MUST restrict their domain of
>>    applicability to the presentation containing the stream.  The safest
>>    way is to simply discard these NAL units and SEI messages.
> 
> Maybe this is due to my ignorance about coding but I find this
> underspecified, notably given the presence of the MUST key word. How
> about spelling exactly what a decoder MUST do, as opposed to say
> "exercise caution". E.g., "Decoders MUST discard NAL units and SEI
> messages.", and then explain why, or point to
> [I-D.ietf-avt-rtp-rfc3984bis] if there's a good explanation there.

The language of this paragraph has been taken from RFC3984, section 9,
fourth paragraph, and has been adapted to changes in H.264 video standard
terminology.

Back in 2004, this paragraph (as the rest of RFC 3984's security
consideration section) has been subject to lengthily deliberations in AVT.
What we arrived at was considered both sufficiently flexible for
implementers and sufficiently cautious to keep security risks at bay.  A
compromise, that was deemed sensible by everyone involved.  We would like to
keep the spirit of this compromise.

The technical issue is as follows: as most video compression standards, SVC
allows to include data into its bitstream that is not intuitively video
related.  For example, there is a copyright message SEI--which almost
certainly has no negative security implications.  However, there is also an
URI SEI message.  If a stupidly designed system would use the URI in the
bitstream without being cautious--ie copying the URI into a web browser just
to see what happens--then all kinds of evil things could happen.  Further,
there are open codepoints both in the SEI message format and in the NAL unit
tables that can and, historically, have be used for vendor specific
extensions.  Vender specific extensions may include stuff such as Java code.
This is what is meant with "active".  The purpose of the paragraph is to
advise implementers not to blindly use any URI they find in the SEI
messages, or the vendor specific extensions, to the non-video decoding part
of the system. 

On the other hand, both the SEI messages and the extension mechanisms are
there for a reason.  Simply requiring discarding information conveyed in
these fields (that may, and in most cases will, have been put there by an
encoder for a reason beyond malicious intent) may well degenerate the
performance of a system to a point where it becomes useless.  Simply
requiring discarding these bits is not a good choice for the RFC, because
such a requirement would not be sensible to many implementations and,
therefore, would be ignored.

We could add explanatory language to the above extent to the draft, and if
you were insisting, we would do so.  However, please bear in mind that the
situation described above is, we believe, well enough understood in the
codec implementer community, and that the draft will be implemented by a
codec guy, and not a protocol guy, because of the close interaction between
codec technology and the payload format.  Further, codec guys are used to
work with the type of dense documents like this draft, that include very
little explanation or justification.  Therefore, we suggest that adding more
information will simply bloat the draft, without adding any critical
information, and suggest to leave that part of the draft as is.

Please let us know you wish us to proceed.

Thanks,
Stephan