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

Roman Danyliw <rdd@cert.org> Thu, 03 June 2021 22:07 UTC

Return-Path: <rdd@cert.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FE23A1C4A; Thu, 3 Jun 2021 15:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a56p8g5Azafq; Thu, 3 Jun 2021 15:07:29 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512F63A1C49; Thu, 3 Jun 2021 15:07:29 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 153M7Qv5042562; Thu, 3 Jun 2021 18:07:26 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 153M7Qv5042562
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1622758046; bh=B3dOTk3IY5oz+VH6w4UAzvTLMb9DhISfdk8SmsqSy/U=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=YtSmIiZWEqqdNauoAlfzspehfY7M2qSiqmMhgvlGWq+lpLg//sIQGV3VVv4qmAtwN 9Ndv/FLPNAVOTN8cddoSqTj725xD1aDUFZTLJtkNjlTerUCZkzCHRYVELNCKa0OKtT SNA5fcLKTr00DWDM+zOkumEmupfIX00b2g/hLUfE=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 153M7NMF015581; Thu, 3 Jun 2021 18:07:23 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 3 Jun 2021 18:07:22 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2242.008; Thu, 3 Jun 2021 18:07:22 -0400
From: Roman Danyliw <rdd@cert.org>
To: Jonathan Lennox <jonathan.lennox@8x8.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-payload-vp9@ietf.org" <draft-ietf-payload-vp9@ietf.org>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "avt@ietf.org" <avt@ietf.org>, "bernard.aboba@gmail.com" <bernard.aboba@gmail.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-payload-vp9-13: (with COMMENT)
Thread-Index: AQHXV8qpO2aKQfngYEa7S6FhUXpIfasDD72A///J/MA=
Date: Thu, 3 Jun 2021 22:07:21 +0000
Message-ID: <ad8388616e9e4db1ae19bbf554d45a5f@cert.org>
References: <162265058467.12641.14507999218364492698@ietfa.amsl.com> <30E6C68D-2D2B-4120-AB7E-E96F575AA8B3@8x8.com>
In-Reply-To: <30E6C68D-2D2B-4120-AB7E-E96F575AA8B3@8x8.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.236]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/_LcSWmLFWFq9vz2kb05240MLexw>
Subject: Re: [AVTCORE] Roman Danyliw's No Objection on draft-ietf-payload-vp9-13: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 22:07:35 -0000

Hi Jonathan!

> -----Original Message-----
> From: Jonathan Lennox <jonathan.lennox@8x8.com>
> Sent: Thursday, June 3, 2021 5:19 PM
> To: Roman Danyliw <rdd@cert.org>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-payload-vp9@ietf.org; avtcore-
> chairs@ietf.org; avt@ietf.org; bernard.aboba@gmail.com
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-payload-vp9-13: (with
> COMMENT)
> 
> 
> 
> > On Jun 2, 2021, at 12:16 PM, Roman Danyliw via Datatracker
> <noreply@ietf.org> 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.

Sounds good.  Thanks.

Regards,
Roman