[payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-payload-rtp-h265-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


(1) For a 99 page detailed specification, the security
considerations are tremendously brief.  There are two
non-boilerplate paragraphs - one says developers "MUST
exercise caution" (meaning what precisely?) and the other
extolls the virtues of not encrypting. For a 99 page
specification of a highly non-trivial encoding scheme, I
would have expected to see the results of a better
analysis. Was that analysis done? That should at least
include consideration of the CVEs already published
relating to H.264 [1] which include 34 CVEs relating to
various kinds of remote-code-execution and DoS. If the
authors here are asserting that this presumably more
complex codec will have few vulnerabilities, then I would
welcome seeing the justification for that statement.
(Note: In some cases with payload drafts, authors can
fairly claim that the I-D does not describe the payload
in detail and hence that the security considerations text
need not be comprehensive as implementers are expected to
find that elsewhere. In this case, the 99 pages strongly
argues otherwise IMO - there are plenty of ways to go
badly wrong implementing what is stated in this draft.)
To summarise: "MUST exercise caution" is not useful,
can't you translate that into actionable advice to an
implementer based on experience with security issues
found with this and similar codecs?

   [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=h.264

(2) This is just a process nit probably. The shepherd
write-up doesn't mention the Nokia IPR declaration.  Were
the WG also ok with that one? The write-up seems to
pre-date that latest IPR declaration, which is from a
company that seems to employ one of the authors. That is
odd timing really so can someone explain the sequence of
events and why all is well?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



- General: I was puzzled as to why there is so much text
that is presumably non-normative explanatory text
covering what is elsewehere in (I guess) ITU documents.
It seems like there is a lot, but not enough, here for an
implementer.

- 4.1: " The assignment of an RTP payload type for this
new packet format is outside the scope of this document
and will not be specified here. " Huh? That's confusing.
For me at least.

- p75 - why would md5 ever be most-preferred these days?
Better to not say that, even in an example. Even better
would be to deprecate md5 even for this non-security
purpose to simplify code-audit. Or, if there is some
reason why e.g. sha256 isn't suited then explaining that
would also help for code-audits.