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

[Jonathan Lennox <[e-mail]>]

> On Jun 2, 2021, at 12:16 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-payload-vp9-13: No Objection
> 
> ----------------------------------------------------------------------
> 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.

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.

Changed parentheses to commas.

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

Fixed.

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

Fixed.