Subject: [AVTCORE] Roman Danyliw's No Objection on draft-ietf-payload-vp9-13: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 02 Jun 2021 09:16:24 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-payload-vp9-13: No Objection

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 DISCUSS and COMMENT positions.

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

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

Thank you to Rifaat Shekh-Yusef for the SECDIR review.

** Section 8. Thanks for mentioning the denial of service via computational
complexity issue.  Since the VP9 spec doesn’t say it, but other codec documents
typically do (RFC6386 and draft-ietf-cellar-ffv1), please also considering
adding a comment about processing un-trusted input.  Roughly:

OLD
   This RTP payload format and its media decoder do not exhibit any
   significant non-uniformity in the receiver-side computational
   complexity for packet processing, and thus are unlikely to pose a
   denial-of-service threat due to the receipt of pathological data.
   Nor does the RTP payload format contain any active content.

NEW
Implementations of this RTP payload format need to take appropriate security
considerations into account.  It is extremely important for the decoder to be
robust against malicious payloads and ensure that they do not cause the decoder
to overrun its allocated memory.  An overrun in allocated memory could lead to
arbitrary code execution by an attacker.  The same applies to the encoder, even
though problems in encoders are typically rarer.

This RTP payload format and its media decoder do not exhibit any significant
non-uniformity in the receiver-side computational complexity for packet
processing, and thus are unlikely to pose a denial-of-service threat due to the
receipt of pathological data.  Nor does the RTP payload format contain any
active content.

** Nits

-- Section 3.  Editorial.  Per “Layers are designed (and MUST be encoded) …”,
it seems odd to have normative language as a parenthetical.

-- Section 3.  Editorial.  s/a the term/the term/

-- Section 6.1.2. Typo. s/ capabilties/ capabilities/

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 3 Jun 2021 17:19:27 -0400

> On Jun 2, 2021, at 12:16 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 

Thanks - added, with some slight re-wording (changed to “malicious or malformed”, and clarified that buffer overruns are not the only possible decoder logic error.)

> it seems odd to have normative language as a parenthetical.

Changed parentheses to commas.

> -- Section 3.  Editorial.  s/a the term/the term/

Fixed.

> -- Section 6.1.2. Typo. s/ capabilties/ capabilities/

Fixed.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 3 Jun 2021 22:07:21 +0000

Hi Jonathan!

> -----Original Message-----
> From: Jonathan Lennox <[email-masked]>
> Sent: Thursday, June 3, 2021 5:19 PM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; avtcore-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-payload-vp9-13: (with
> COMMENT)
> 
> 
> 
> > ** Section 8. Thanks for mentioning the denial of service via
> > computational complexity issue.  Since the VP9 spec doesn’t say it,
> > but other codec documents typically do (RFC6386 and
> > draft-ietf-cellar-ffv1), please also considering adding a comment about
> processing un-trusted input.  Roughly:
> >
> > OLD
> > Implementations of this RTP payload format need to take appropriate
> > security considerations into account.  It is extremely important for
> > the decoder to be robust against malicious payloads and ensure that
> > they do not cause the decoder to overrun its allocated memory.  An
> > overrun in allocated memory could lead to arbitrary code execution by
> > an attacker.  The same applies to the encoder, even though problems in
> encoders are typically rarer.
> >
> > denial-of-service threat due to the receipt of pathological data.  Nor
> > does the RTP payload format contain any active content.
> 
> Thanks - added, with some slight re-wording (changed to “malicious or
> malformed”, and clarified that buffer overruns are not the only possible
> decoder logic error.)
> 
> > ** Nits
> >
> > -- Section 3.  Editorial.  Per “Layers are designed (and MUST be
> > encoded) …”, it seems odd to have normative language as a parenthetical.
> 

Sounds good.  Thanks.

Regards,
Roman