Subject: Re: [Cellar] FW: New Version Notification - draft-ietf-cellar-ffv1-18.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 21 Oct 2020 13:03:21 -0500

Hi, Roman,

On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw <[email-masked]> wrote:

> Hi!
> (I can't find your response email to my ballot in my mail client despite
> it being in the archive, so apologizes for making the new thread).
>
> Thanks for the -18 which cleared most of the COMMENTs.  I updated my
> ballot.
>
> In the spirit of clearing what I consider a straightforward DISCUSS, might
> I suggest:
>
> OLD
>
>   Implementations of the FFV1 codec need to take appropriate security
>    considerations into account, as outlined in [RFC4732].  It is
>    extremely important for the decoder to be robust against malicious
>    payloads.  Malicious payloads MUST NOT cause the decoder to overrun
>    its allocated memory or to take an excessive amount of resources to
>    decode.  The same applies to the encoder, ...
>
> NEW
>
> Implementations of the FFV1 codec need to take appropriate security
> considerations into account.  Those related to denial of service are
> outlined in Section 2.1 of [RFC4732].  It is extremely important for the
> decoder to be robust against malicious payloads.  Malicious payloads MUST
> NOT cause the decoder to overrun its allocated memory or to take an
> excessive amount of resources to decode.    An overrun in allocated memory
> could lead to arbitrary code execution by an attacker.  The same applies to
> the encoder, ...
>
> Regards,
> Roman
>

Thanks for this! and I am including the working group in my reply, so
everyone will see it.

Best,

Spencer

>
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Wednesday, October 7, 2020 12:52 PM
> To: Michael Richardson <[email-masked]>; [email-masked];
> [email-masked]; Roman Danyliw <[email-masked]>; Peter B. <
> [email-masked]>
> Subject: New Version Notification - draft-ietf-cellar-ffv1-18.txt
>
>
> A new version (-18) has been submitted for draft-ietf-cellar-ffv1:
> https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.txt
> https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/
>
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-18
>
> Please note that it may take a couple of minutes from the time of
> submission until the diff is available at tools.ietf.org.
>
> IETF Secretariat.
>
>
>

---

From: Dave Rice <[email-masked]>
Date: Fri, 30 Oct 2020 13:41:51 -0400

Thank you Roman,

> On Oct 21, 2020, at 2:03 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Roman,
> 
> On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw <[email-masked] <mailto:[email-masked]>> wrote:
> Hi!
> (I can't find your response email to my ballot in my mail client despite it being in the archive, so apologizes for making the new thread).
> 
> Thanks for the -18 which cleared most of the COMMENTs.  I updated my ballot.
> 
> In the spirit of clearing what I consider a straightforward DISCUSS, might I suggest:
> 
> OLD
> 
> Implementations of the FFV1 codec need to take appropriate security considerations into account.  Those related to denial of service are outlined in Section 2.1 of [RFC4732].  It is extremely important for the decoder to be robust against malicious payloads.  Malicious payloads MUST NOT cause the decoder to overrun its allocated memory or to take an excessive amount of resources to decode.    An overrun in allocated memory could lead to arbitrary code execution by an attacker.  The same applies to the encoder, ...

The recommendation looks appropriate to me and more clear. I moved it to a pull request at https://github.com/FFmpeg/FFV1/pull/253 for the consideration of the other authors.
Kind Regards,
Dave Rice

> Regards,
> Roman
> 
> Thanks for this! and I am including the working group in my reply, so everyone will see it.
> 
> Best,
> 
> Spencer
>  
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Michael Richardson <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Roman Danyliw <[email-masked] <mailto:[email-masked]>>; Peter B. <[email-masked] <mailto:[email-masked]>>
> https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.txt <https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.txt>
> https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html <https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html>
> 
> 
> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ <https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-18 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-18>
> 
> Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org <http://tools.ietf.org/>.
> 
> IETF Secretariat.
> 
> 
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar