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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 01 Sep 2015 05:49:47 -0700

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.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 02 Sep 2015 15:12:57 -0500

Hi,

Stephen's discuss item 2 pointed out that we had a late IPR disclosure 
on this draft after the publication request. I am in discussions with 
the chairs on how to handle this.  I have removed it from the agenda for 
the September 3 telechat. I hope to put it on a future telechat once we 
agree on a way forward.

Thanks!

Ben.

[...]

> events and why all is well?

[...]

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Wed, 2 Sep 2015 22:50:51 +0000

Hi Ben, All,

The authors are discussing on how to address Stephen Farrell's DISCUSS and Barry Leiba's comments. We will send our collectively responses once they are ready. 

However, for the one related to the Nokia IPR statement, per Miska Hannuksela, the co-author who works for Nokia, the (so-called late) Nokia IPR statement (http://datatracker.ietf.org/ipr/2508/) re-iterates the IPR statement that was submitted against draft-schierl-payload-rtp-h265 (https://datatracker.ietf.org/ipr/1753/). Hence, the WG should have been aware of the situation since 00 version of the Schierl draft.

I therefore request to check whether it is possible not to delay the progress of this document because of this. Thanks!

BR, YK

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, September 02, 2015 1:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Stephen Farrell
Subject: Re: Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT)

Hi,

Stephen's discuss item 2 pointed out that we had a late IPR disclosure on this draft after the publication request. I am in discussions with the chairs on how to handle this.  I have removed it from the agenda for the September 3 telechat. I hope to put it on a future telechat once we agree on a way forward.

Thanks!

Ben.

[...]

>
>
> (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?

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 02 Sep 2015 18:36:05 -0500

On 2 Sep 2015, at 17:50, Wang, Ye-Kui wrote:

> Hi Ben, All,
>
> The authors are discussing on how to address Stephen Farrell's DISCUSS 
> and Barry Leiba's comments. We will send our collectively responses 
> once they are ready.
>

Thanks for doing that.

> However, for the one related to the Nokia IPR statement, per Miska 
> Hannuksela, the co-author who works for Nokia, the (so-called late) 
> Nokia IPR statement (http://datatracker.ietf.org/ipr/2508/) 
> re-iterates the IPR statement that was submitted against 
> draft-schierl-payload-rtp-h265 
> (https://datatracker.ietf.org/ipr/1753/). Hence, the WG should have 
> been aware of the situation since 00 version of the Schierl draft.
>
> I therefore request to check whether it is possible not to delay the 
> progress of this document because of this. Thanks!

Thanks for that information. I think that clears the authors from any 
blame for not making a timely disclosure.

But I don't think that's sufficient to avoid a delay, for a couple of 
reasons. First, saying the work group "should have been aware" is not 
sufficient. The work group needs to agree that it is willing to progress 
a document with an IPR disclosure. A "should have been aware" standard 
makes it to easy for people to simply not notice.

The second is, there's no evidence in the tracker that 
draft-ietf-payload-rtp-h265 was a replacement to 
draft-schierl-payload-rtp-h265. I don't mean to say that it's not, just 
that the datatracker "replaces" field does not show it. Without the 
replaces information, an IPR search on draft-ietf-payload-rtp-h265 does 
not show the disclosure for the older draft. Now, I recognize this is a 
silly clerical issue--but the effect is that working group participants 
were highly likely to miss the existence of the older disclosure when 
considering draft-ietf-payload-rtp-h265.

It's too late to put the draft back on tomorrow's telechat in any case. 
But if the chairs make a working group consensus call concerning the 
Nokia disclosure in the next few days, and the results are to proceed, I 
will put it back on the earliest possible telechat agenda.

Thanks!

Ben.

> Subject: Re: Stephen Farrell's Discuss on 
> draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT)
>
> Hi,
>
> the chairs on how to handle this.  I have removed it from the agenda 
> for the September 3 telechat. I hope to put it on a future telechat 
> once we agree on a way forward.
>
> Thanks!
>
> Ben.
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 02 Sep 2015 18:40:03 -0500

On 2 Sep 2015, at 18:36, Ben Campbell wrote:

>> The authors are discussing on how to address Stephen Farrell's 
>> DISCUSS and Barry Leiba's comments. We will send our collectively 
>> responses once they are ready.
>>
>
> Thanks for doing that.
>
> sufficient. The work group needs to agree that it is willing to 
> progress a document with an IPR disclosure. A "should have been aware" 
> standard makes it to easy for people to simply not notice.
>
> draft-schierl-payload-rtp-h265. I don't mean to say that it's not, 
> just that the datatracker "replaces" field does not show it. Without 
> the replaces information, an IPR search on draft-ietf-payload-rtp-h265 
> does not show the disclosure for the older draft. Now, I recognize 
> this is a silly clerical issue--but the effect is that working group 
> participants were highly likely to miss the existence of the older 
> disclosure when considering draft-ietf-payload-rtp-h265.
>
> It's too late to put the draft back on tomorrow's telechat in any 
> case. But if the chairs make a working group consensus call concerning 
> the Nokia disclosure in the next few days, and the results are to 
> proceed, I will put it back on the earliest possible telechat agenda.

Oops, I meant to add "or point me to where the working group explicitly 
discussed the disclosure with respect to draft-ietf-payload-rtp-h265".

Ben.

>> Stephen's discuss item 2 pointed out that we had a late IPR 
>> disclosure on this draft after the publication request. I am in 
>> discussions with the chairs on how to handle this.  I have removed it 
>> from the agenda for the September 3 telechat. I hope to put it on a 
>> future telechat once we agree on a way forward.
>>
>> Thanks!
>>
>> Ben.
>>

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Thu, 3 Sep 2015 01:06:13 +0000

Thanks for the clarifications!

Reminded by your comments below, I further checked and noticed that the Qualcomm IPR declaration (https://datatracker.ietf.org/ipr/2118/) that was made on the individual draft was not included in the list of IPR declarations during the last calls too. My search did not indicate other IPR declarations possibly not (fully) mentioned during last calls.

WG chairs, please take this into account too when addressing Ben's request below.

BR, YK

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Wednesday, September 02, 2015 4:40 PM
To: Wang, Ye-Kui
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Stephen Farrell
Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT)

> proceed, I will put it back on the earliest possible telechat agenda.

Oops, I meant to add "or point me to where the working group explicitly discussed the disclosure with respect to draft-ietf-payload-rtp-h265".

Ben.

>>> (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?

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 4 Sep 2015 21:07:44 +0000

Hi Stephen, all,
With all respect due, this appears to us authors as one or the more sloppy reviews of the security consideration section and security features of the document.  Please see our comments inline.
Regards,
Stephan

On 9/1/15, 05:49, "Stephen Farrell" <[email-masked]> wrote:

>exercise caution" (meaning what precisely?) 

The third paragraph says developers MUST use caution with respect to a very specific codepoint in the codec spec, namely the user data SEI messages.  But also please see below.

>and the other
>extolls the virtues of not encrypting. 

The fourth paragraph simply states that the middlebox called MANE as used in this doc (and as used in many current video conferencing systems) is incompatible with end-to-end encryption.  The IETF tries to solve that vulnerability in the perc WG.  Until such solutions are widely deployed, it’s probably appropriate to warn people of certain features of MANEs.

>For a 99 page
>analysis. Was that analysis done? 

To the extent an analysis is required for the RTP payload specification, the answer is yes, it was done; and no, no vulnerabilities beyond those mentioned were found.  We neither analyzed the security aspects of RTP itself, nor in much detail the security aspects of H.265, although we point out the one vulnerability that is perhaps not commonly known and well understood in the third paragraph (the one with the “MUST exercise caution”).

>That should at least
>various kinds of remote-code-execution and DoS. 

We were not aware of the existence of CVEs allegedly related to H.264 and its transport specs.  Thanks for pointing it out.

Upon brief review, none of the 34 CVEs relate to H.264 over RTP in any way, shape, or form.

Every one relates to an implementation problem, and NOT to a specification problem.  Some of them clearly are mischaracterized by the search engine or the filers; certainly, problems with SMTP, RTSP, file name parsing etc. have nothing to do with video codecs or RTP.  They are irrelevant here.  Many appear to be duplicates, or at least reporting the same source of a problem leading to different vulnerabilities.  Of those directly related to codec implementations, they pretty much all refer to vulnerabilities that open when feeding either non-compliant, or compliant but “evil” bitstreams to decoders.  Those are the only ones we possibly could do something about.

The second paragraph (one of those you labelled as “boilerplate”) deals with exactly those vulnerabilities and recommends a solution.

There is very little we can recommend beyond what is in the second paragraph to a codec implementer regarding the decoder’s reaction to non-compliant bitstreams.  The only thing that comes to mind is to say that even in case of applied end-to-end security attackers may feed non-compliant bitstreams to an unaware system, and that system better does not crash and burn over those bitstreams but gracefully discard them or something.  With respect to “evil” bitstreams, we could point out that the video codec standardization community has long recognized their existence (for reasons completely unrelated to security), and publishes a set of test “evil” bitstreams designed to check many of the stress points of a decoder implementation.  It’s quite obvious that many of the open source folks building decoders, as well as some early commercial H.264 decoder implementations, did not run tests against those bitstreams--or ran the tests, knew about the vulnerability, but decided that performance is more important than stability and security against theoretical threat scenarios.  We could point out that it is prudent for a decoder implementer to run its implementation at least against published known “evil” bitstreams.  But that’s all we can possibly do with respect to codec implementations.  

All the shmuh above is probably useful input for the security considerations section of IETF video codecs as designed by netvc.  They do not necessarily belong to an RTP payload spec, but if you prefer we will add them nevertheless.

>If the

No one but us (in the third paragraph) has pointed out a security vulnerability in spec space.  We can’t really combat shoddy implementation practices.

>badly wrong implementing what is stated in this draft.)

Agreed in principle.  But we are not aware of anything that can go wrong within the protocol designed in the 99 pages beyond what we pointed out in the fourth paragraph--and yes, we looked.

>found with this and similar codecs?

So let’s look in more detail at the “MUST exercise caution”.  The offending paragraph reads:
“Decoders MUST exercise caution with respect to the handling of user data SEI messages, particularly if they contain active elements, and MUST restrict their domain of applicability to the presentation of the bitstream.” 
We point out one H.264/H.265 codec specific potential vulnerability perhaps not well understood by some people (as it is pretty exotic)--the “user data Supplementary Enhancement Information (SEI) message”.  Video codec implementers--the main audience for this spec--know what SEI messages are, but not necessarily this one.  The user data SEI allows an encoder to embed into the video bitstream pretty much any bitstring up to a certain (in many cases quite large) length.  Machine code, Javascript, ..., anything.  Obviously, this can be dangerous.  However, it is also useful and used in practice in some of today’s systems (though not necessarily with active content).  Insofar, we do not require a receiver to discard this potentially dangerous (but often quite useful) data.  Instead, we say that a decoder must be careful around these bits, and restrict their use to the rendering subsystem.  If implemented correctly, the worse that would happen is a messed up video picture.
You suggest that “MUST exercise caution” is not actionable, and upon reflection we agree.  Informative language appears to be more appropriate.  We could remove the “caution” language and just stay with the clearly actionable other remedy, or we could soften the “caution” language to something like “decoder implementers have to weight the potential benefits of using active content against their dangers.  One way to do so is to restrict the domain of applicability to the presentation of the bitstream.”.  Does this address your concern?

>events and why all is well?

I will leave the chairs and Ben to sort this out.  However, I remember quite clearly that I myself pointed out during IETF payload sessions the Nokia IPR at least once, including my understanding of the scope of protection and its limitation to certain optional modes of operation.  I don’t believe that these discussions were minuted, but they probably can be found in audio records.  In other words, yes, the Nokia IPR was raised in the WG, and in a level of detail rather uncommon for such discussions.  Really, no regular follower of the payload WG should be surprised of this.

The WG heard this comment before and discussed it.  It is my understanding of the WG consensus that the level of detail is about right.  For your information, the H.265 version 1 spec is an extremely dense document (much denser than the payload format) and, set out in 10 pt. Times Roman, spans 300 pages.  We cover the core codec only superficially, but dig in a bit deeper in those aspects where we added signaling support for capability exchange (for example, parallelization tools). 

>and will not be specified here. " Huh? That's confusing.

This is common text among many other RTP payload formats.  Historically, RTP payload formats (or RTP profiles) hard-coded the RTP payload type for a media format.  Today, the assignment of the RTP payload type is handled dynamically by the call control protocol, for example by SIP.  I don’t think that this paragraph is confusing to anyone familiar with RTP.

>would also help for code-audits.

The code point your comment relates to is available to negotiate the capability to include a certain SEI message (namely the decoded picture hash (DPH) SEI message) into the H.265 bitstream.  We are therefore restricted to the syntax of that SEI message.  The DPH offers the choice of an MD5 checksum, a 16 bit CRC or a 32 bit add-until wraparound checksum.  Please refer to the cited paragraphs in H.265 to the available options.  Of these, we recommend the most sophisticated one (and this is inline with current implementation practice; for example, the H.265 reference code includes DPHs using the MD5 checksum).
Speculating a bit why ITU and ISO/IEC uses these (and not other, more sophisticated) checksums, I guess MD5 was chosen as it is sufficient for the purpose.  Including the DPH is mostly a crude error detection tool.  It’s unrelated to security.  In any case, it’s not up to a RTP payload format document to question the design choices made by the payload standardizers.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 04 Sep 2015 17:05:01 -0500

On 4 Sep 2015, at 16:07, Stephan Wenger wrote:

> I will leave the chairs and Ben to sort this out.  However, I remember 
> quite clearly that I myself pointed out during IETF payload sessions 
> the Nokia IPR at least once, including my understanding of the scope 
> of protection and its limitation to certain optional modes of 
> operation.  I don’t believe that these discussions were minuted, but 
> they probably can be found in audio records.  In other words, yes, the 
> Nokia IPR was raised in the WG, and in a level of detail rather 
> uncommon for such discussions.  Really, no regular follower of the 
> payload WG should be surprised of this.

There's a separate discussion of the IPR issue (and that has turned up a 
QualComm disclosure that was showing in the tracker for the same reason 
the Nokia one did not.) My personal opinion is that we need to follow a 
higher standard than "people should be aware/not surprised"; we really 
explicit WG discussion about whether it wants to progress the draft in 
the face of a disclosure.

That being said, do you know (or can you guess) which meeting might have 
an audio record of the discussion?

Thanks!

Ben.

---

From: "Roni Even" <[email-masked]>
Date: Sun, 6 Sep 2015 00:17:55 +0300

Hi Stephan,
I am trying to remember but this Nokia IPR was submitted December 2014 after we sent the document to publication and we had two meetings since (Dallas and Prague). Was it discussed before on earlier version of the document?
Roni

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Saturday, September 05, 2015 1:05 AM
To: Stephan Wenger
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]; Stephen Farrell
Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT)

On 4 Sep 2015, at 16:07, Stephan Wenger wrote:

>> 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?
>
>

There's a separate discussion of the IPR issue (and that has turned up a QualComm disclosure that was showing in the tracker for the same reason the Nokia one did not.) My personal opinion is that we need to follow a higher standard than "people should be aware/not surprised"; we really explicit WG discussion about whether it wants to progress the draft in the face of a disclosure.

That being said, do you know (or can you guess) which meeting might have an audio record of the discussion?

Thanks!

Ben.

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 6 Sep 2015 03:31:07 +0000

>I am trying to remember but this Nokia IPR was submitted December 2014 after we sent the document to publication and we had two meetings since (Dallas and Prague). Was it discussed before on earlier…

The Nokia IPR was discussed way earlier, probably around the Berlin IETF.  Let me dig a bit...
Stephan

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 05 Sep 2015 23:18:23 -0500

Hi Roni,

It may have been buried in tall the emails, but my understanding is the 
Dec 2014 Nokia disclosure was an update of an earlier disclosure made 
against the pre-wg version of the draft. But because the tracker does 
not show payload-rtp-h265 as replacing the older version, it didn't 
apply the earlier discloser to the working group draft.

Ben.

On 5 Sep 2015, at 22:31, Stephan Wenger wrote:

>> I am trying to remember but this Nokia IPR was submitted December 
>> 2014 after we sent the document to publication and we had two 
>> meetings since (Dallas and Prague). Was it discussed before on 
>> earlier version of the document?
>
>> Cc: [email-masked]; [email-masked]; 
>> The IESG; [email-masked]; Stephen Farrell
>> Subject: Re: [payload] Stephen Farrell's Discuss on 
>> There's a separate discussion of the IPR issue (and that has turned 
>> up a QualComm disclosure that was showing in the tracker for the same 
>> reason the Nokia one did not.) My personal opinion is that we need to 
>> follow a higher standard than "people should be aware/not surprised"; 
>> we really explicit WG discussion about whether it wants to progress 
>> the draft in the face of a disclosure.
>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Sep 2015 14:32:48 +0100

Hiya,

Sorry for the slow response ...

On 04/09/15 22:07, Stephan Wenger wrote:
> Hi Stephen, all, With all respect due, this appears to us authors as
> one or the more sloppy reviews of the security consideration section
> and security features of the document.  

Hmm. I can see how a "please show your work, because I'm not sure it's
been done" discuss may be irritating at this point in what was probably
a very long and already irritating process, but I don't agree that
sloppy is at all a good descriptor for that.

Anyway, some more below, but maybe we should think about how best to
resolve the discuss and not get too wrapped around blow-by-blow
responses which could easily happen here and not get us too far. Could
be that a call is the way to do that. If so, I'm happy to do one.
(And do feel free to not respond to everything below.)

> Please see our comments
> inline. Regards, Stephan
>> non-boilerplate paragraphs - one says developers "MUST exercise
>> caution" (meaning what precisely?)
> 
> The third paragraph says developers MUST use caution with respect to
> a very specific codepoint in the codec spec, namely the user data SEI
> messages.  But also please see below.

"MUST use caution" isn't really a sensible use of a 2119 MUST. It
needs to be something a developer can interpret, and it's not clear
to me that that is. (And also more below too.)

> 
> 
>> and the other extolls the virtues of not encrypting.
> 
> The fourth paragraph simply states that the middlebox called MANE as
> used in this doc (and as used in many current video conferencing
> systems) is incompatible with end-to-end encryption.  The IETF tries
> to solve that vulnerability in the perc WG.  Until such solutions are
> widely deployed, it’s probably appropriate to warn people of certain
> features of MANEs.
> 
> 
> 
>> For a 99 page specification of a highly non-trivial encoding
>> scheme, I would have expected to see the results of a better 
> To the extent an analysis is required for the RTP payload
> specification, the answer is yes, it was done; and no, no
> vulnerabilities beyond those mentioned were found.  

Great. Can you send me a pointer to where that was described on
the wg list or in a meeting?

> We neither
> analyzed the security aspects of RTP itself, nor in much detail the
> security aspects of H.265, 

That's the norm in the payload WG. However, this draft does not fit
that normal pattern since it has such a large amount of new text.

For example, I searched for the first substantive " must " in the
document. That's on page 9, para 2 and says "must contain an end of
bitstream NAL unit and..." (various other conditions) but that
doesn't say what an implementer should do if those conditions are
not met. And I could see crafted packets not meeting those conditions
and perhaps leading to remote code execution.

The subsequent paragraphs also generate security concerns, dealing
as they do with random access - messing with whatever pointers are
used for that could cause lots of implementation errors/crashes.

Now, are either of those things new (in this draft) and not described
in the ITU documents? I don't know is the answer, but presumably you
do. I'd guess they probably are in the ITU specs in this case, but
equally I might guess that the ITU specs also don't contain guidance
as to how to handle failure cases. That lack of guidance does I think
increase the liklihood of implementation error.

And you're adding some guidance here, so I don't get why that guidance
doesn't extend to security considerations.

> although we point out the one
> vulnerability that is perhaps not commonly known and well understood
> in the third paragraph (the one with the “MUST exercise caution”).
> 
> 
>> That should at least include consideration of the CVEs already
>> published relating to H.264 [1] which include 34 CVEs relating to 
> We were not aware of the existence of CVEs allegedly related to H.264

Allegedly? This isn't a court, it's a DISCUSSion:-)

> and its transport specs.  Thanks for pointing it out.
> 

So you'd not previously searched for related CVEs? That is one good
way to find out what implementers have done wrong in the past and
so are likely to do again. Not the only way, but one.

> 
> Every one relates to an implementation problem, and NOT to a
> specification problem.  Some of them clearly are mischaracterized by
> the search engine or the filers; certainly, problems with SMTP, RTSP,
> file name parsing etc. have nothing to do with video codecs or RTP.
> They are irrelevant here.  Many appear to be duplicates, or at least
> reporting the same source of a problem leading to different
> vulnerabilities.  Of those directly related to codec implementations,
> they pretty much all refer to vulnerabilities that open when feeding
> either non-compliant, or compliant but “evil” bitstreams to decoders.
> Those are the only ones we possibly could do something about.

That's fair. And what guidance is offered for that last kind of case?
(Other than the one discussed below.)

> 
> The second paragraph (one of those you labelled as “boilerplate”)
> deals with exactly those vulnerabilities and recommends a solution.

To an extent. DAO and data integrity do help yes, but RTP will often
be used without those. At that point the implementer needs guidance.
And the issue is less with "overload" and more with allowing remote
code execution.

> 
> There is very little we can recommend beyond what is in the second
> paragraph to a codec implementer regarding the decoder’s reaction to
> non-compliant bitstreams.  The only thing that comes to mind is to
> say that even in case of applied end-to-end security attackers may
> feed non-compliant bitstreams to an unaware system, and that system
> better does not crash and burn over those bitstreams but gracefully
> discard them or something.  With respect to “evil” bitstreams, we
> could point out that the video codec standardization community has
> long recognized their existence (for reasons completely unrelated to
> security), and publishes a set of test “evil” bitstreams designed to

I didn't know that. Do those include cases that might lead to remote
code execution? (Just wondering.) Have you pointers?

> check many of the stress points of a decoder implementation.  It’s
> quite obvious that many of the open source folks building decoders,
> as well as some early commercial H.264 decoder implementations, did
> not run tests against those bitstreams--or ran the tests, knew about
> the vulnerability, but decided that performance is more important
> than stability and security against theoretical threat scenarios.  We
> could point out that it is prudent for a decoder implementer to run
> its implementation at least against published known “evil”
> bitstreams. 

I think that would be worthwhile, esp. if as you say it could
have helped avoid some implementation errors.

> But that’s all we can possibly do with respect to codec
> implementations.

That's where I'm not sure and where the 99 pages aspect comes in.
You've described so much about this, I can't see why you omit the
security considerations.

> 
> All the shmuh above is probably useful input for the security
> considerations section of IETF video codecs as designed by netvc.
> They do not necessarily belong to an RTP payload spec, but if you
> prefer we will add them nevertheless.
> 
> 
> 
>> 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.
> 
> No one but us (in the third paragraph) has pointed out a security
> vulnerability in spec space.  We can’t really combat shoddy
> implementation practices.

Combat is the wrong word. What's needed here is to document the
security considerations of the specification text that's in this
document.

> 
> 
>> (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.)
> 
> Agreed in principle.  But we are not aware of anything that can go
> wrong within the protocol designed in the 99 pages beyond what we
> pointed out in the fourth paragraph--and yes, we looked.

Again, if you could point out where that was described to the WG
that'd be great.

> 
> 
> 
>> 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?
> 
> So let’s look in more detail at the “MUST exercise caution”.  The
> offending paragraph reads: “Decoders MUST exercise caution with
> respect to the handling of user data SEI messages, particularly if
> they contain active elements, and MUST restrict their domain of
> applicability to the presentation of the bitstream.” We point out one
> H.264/H.265 codec specific potential vulnerability perhaps not well
> understood by some people (as it is pretty exotic)--the “user data
> Supplementary Enhancement Information (SEI) message”.  Video codec
> implementers--the main audience for this spec--know what SEI messages
> are, but not necessarily this one.  The user data SEI allows an
> encoder to embed into the video bitstream pretty much any bitstring
> up to a certain (in many cases quite large) length.  Machine code,
> Javascript, ..., anything.  Obviously, this can be dangerous.
> However, it is also useful and used in practice in some of today’s
> systems (though not necessarily with active content).  Insofar, we do
> not require a receiver to discard this potentially dangerous (but
> often quite useful) data.  Instead, we say that a decoder must be
> careful around these bits, and restrict their use to the rendering
> subsystem.  If implemented correctly, the worse that would happen is
> a messed up video picture. You suggest that “MUST exercise caution”
> is not actionable, and upon reflection we agree.  Informative
> language appears to be more appropriate.  We could remove the
> “caution” language and just stay with the clearly actionable other
> remedy, or we could soften the “caution” language to something like
> “decoder implementers have to weight the potential benefits of using
> active content against their dangers.  One way to do so is to
> restrict the domain of applicability to the presentation of the
> bitstream.”.  Does this address your concern?

I'm not sure the latter (alone) is much better tbh. What's needed is
something that a developer who is implementing the rest of this draft
can easily comprehend. Explaining the trade-offs is a fine thing to
do, but in the above, many implementers won't weigh costs/benefits,
they'll just write their code;-)

So explaining the attack (in a sentence), mentioning the trade offs
(in a sentence) and then saying something like "to be safe do X."
In this case, I'm not sure "restrict domain..." is a correct X, since
active content could e.g. take over the entire screen in which case
there is no really safe way to handle it unless you first check the
specific content. I'd say that disabling all active content is
really the only safe instruction that can be given, if that is
practical (I'm not sure if it is).

>> 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?
> 
> I will leave the chairs and Ben to sort this out.  However, I
> remember quite clearly that I myself pointed out during IETF payload
> sessions the Nokia IPR at least once, including my understanding of
> the scope of protection and its limitation to certain optional modes
> of operation.  I don’t believe that these discussions were minuted,
> but they probably can be found in audio records.  In other words,
> yes, the Nokia IPR was raised in the WG, and in a level of detail
> rather uncommon for such discussions.  Really, no regular follower of
> the payload WG should be surprised of this.

Ben is handling this separately.

>> 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.
> 
> The WG heard this comment before and discussed it. 

Cool - can you also send me a point to that discussion so I can
understand it better? (It still puzzles me tbh.)

> It is my
> understanding of the WG consensus that the level of detail is about
> right.  For your information, the H.265 version 1 spec is an
> extremely dense document (much denser than the payload format) and,
> set out in 10 pt. Times Roman, spans 300 pages.  We cover the core
> codec only superficially, but dig in a bit deeper in those aspects
> where we added signaling support for capability exchange (for
> example, parallelization tools).
> 
>> 
>> - 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.
> 
> This is common text among many other RTP payload formats.
> Historically, RTP payload formats (or RTP profiles) hard-coded the
> RTP payload type for a media format.  Today, the assignment of the
> RTP payload type is handled dynamically by the call control protocol,
> for example by SIP.  I don’t think that this paragraph is confusing
> to anyone familiar with RTP.
> 
>> 
>> - 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.
> 
> The code point your comment relates to is available to negotiate the
> capability to include a certain SEI message (namely the decoded
> picture hash (DPH) SEI message) into the H.265 bitstream.  We are
> therefore restricted to the syntax of that SEI message.  The DPH
> offers the choice of an MD5 checksum, a 16 bit CRC or a 32 bit
> add-until wraparound checksum.  Please refer to the cited paragraphs
> in H.265 to the available options.  Of these, we recommend the most
> sophisticated one (and this is inline with current implementation
> practice; for example, the H.265 reference code includes DPHs using
> the MD5 checksum). Speculating a bit why ITU and ISO/IEC uses these
> (and not other, more sophisticated) checksums, I guess MD5 was chosen
> as it is sufficient for the purpose.  Including the DPH is mostly a
> crude error detection tool.  It’s unrelated to security.  In any
> case, it’s not up to a RTP payload format document to question the
> design choices made by the payload standardizers.

Bummer that they've kept md5.

FWIW, in such cases I'd choose crc32 myself. Using md5 causes
problems (i.e. cost) for folks doing security code audits when
the auditor has to have it explained/documented why there is any
md5 code still being used and why that isn't security sensitive
and how one ensures no security sensitive bits of code re-use that
md5 implementation. (It's generally a bad plan to continue to use
broken crypto for anything I think. But people do do it.)

Cheers,
S.