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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 09 Jun 2021 12:34:32 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-payload-rtp-jpegxs-15: 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-rtp-jpegxs/

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

** Section 4.1. Typo. s/preceeded/preceded/

** Section 10.  . Thanks for mentioning the possibility of a denial of service
due computational complexity.   Please considering adding a comment about
processing untrusted input (similar to the language in other RTP payload drafts
like: draft-ietf-payload-vp9 and draft-ietf-cellar-ffv1).  Roughly:

OLD
   This payload format and the JPEG XS encoding do not exhibit any
   substantial non-uniformity, ...

NEW

Implementations of this RTP payload format need to take appropriate security
considerations into account.  It is important for the decoder to be robust
against malicious or malformed payloads and     ensure that they do not cause
the decoder to overrun its allocated memory or otherwise misbehave.  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 payload format and the JPEG XS encoding do not exhibit any substantial
non-uniformity, ...

---

From: Tim Bruylants <[email-masked]>
Date: Thu, 10 Jun 2021 06:48:50 +0000

Thank you for the review and feedback.

I have prepared a new draft document that addresses your comments.

> ** Section 4.1. Typo. s/preceeded/preceded/

Fixed.

> Implementations of this RTP payload format need to take appropriate security considerations into account.  It is important for the decoder to be robust
> the decoder to overrun its allocated memory or otherwise misbehave.  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 payload format and the JPEG XS encoding do not exhibit any substantial non-uniformity, ...

Indeed, this is very useful to explain. Somehow it seems so obvious that we did not think about writing it down. Thanks for the suggestion.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 10 Jun 2021 01:01:04 -0700

On Wed, Jun 9, 2021 at 11:49 PM Tim Bruylants <[email-masked]> wrote:

> [...]

I assume that means there will be a -16 that's ready for the RFC Editor
queue, correct?

-MSK

---

From: Tim Bruylants <[email-masked]>
Date: Thu, 10 Jun 2021 08:17:43 +0000

Hi, I suppose so.

I uploaded -16 to address your suggestions (the only changes are related to your input). I hope this was the correct action to take.

Regards,
Tim.

From: Murray S. Kucherawy <[email-masked]>
Sent: Thursday 10 June 2021 10:01
To: Tim Bruylants <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; Ali Begen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Roman Danyliw's No Objection on draft-ietf-payload-rtp-jpegxs-15: (with COMMENT)

On Wed, Jun 9, 2021 at 11:49 PM Tim Bruylants <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for the review and feedback.

I assume that means there will be a -16 that's ready for the RFC Editor queue, correct?

-MSK

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 10 Jun 2021 12:35:37 +0000

Hi Tim!

Top posting only to say thanks for the quick turn-around and the updated -16 draft.  I've cleared my ballot.

Regards,
Roman

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Tim Bruylants
> Sent: Thursday, June 10, 2021 2:49 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Ali Begen
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-payload-rtp-jpegxs-15:
> (with COMMENT)
> 
> > Implementations of this RTP payload format need to take appropriate
> security considerations into account.  It is important for the decoder to be
> robust
> > the decoder to overrun its allocated memory or otherwise misbehave.  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.
> >
> Indeed, this is very useful to explain. Somehow it seems so obvious that we did
> not think about writing it down. Thanks for the suggestion.