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

Jonathan Lennox <jonathan.lennox@8x8.com> Thu, 03 June 2021 21:19 UTC

Return-Path: <jonathan.lennox@8x8.com>
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 799813A1AAF for <avt@ietfa.amsl.com>; Thu, 3 Jun 2021 14:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.com
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 UHUPW6D3L_W1 for <avt@ietfa.amsl.com>; Thu, 3 Jun 2021 14:19:31 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99AB3A1AB2 for <avt@ietf.org>; Thu, 3 Jun 2021 14:19:30 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id k11so5773487qkk.1 for <avt@ietf.org>; Thu, 03 Jun 2021 14:19:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=quKBxXXL/shKvB8rb1jvCvWWIOfLk/5iHUSLPUFoatw=; b=MBUxBOBFZ/G47gyRc6AX+qX44bMNgQQ5oSuq1Bi5EuibbfO4L/rtadwTqnPzLNhIve D7MnolyLu2yNOjgTmnJJ+ngEHOeOxWnJ8Vrg8SYgW7SR/enqJchjCH8thVPEyLl2fS9I 0emlDnPYgHWIFA+l+5z+SKA3mgYee0fpjY790=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=quKBxXXL/shKvB8rb1jvCvWWIOfLk/5iHUSLPUFoatw=; b=qQi1Z1tkfrP4G6l13sl11X2sHvY2lNU/XZzPupoxIySeNNrWRXGzkKG013X4Z5g9yM rj6dnLKWeiLeN6dL/hcvlOSZB/9RxFUaarOW2gVFxIrSghk6nJqnD36kUJcu7VRJ/bFy K72T1c4lZe8SMLFzzS3PKbBNgyg0RS7oi58n3/E2DpLWqsnLaRBYV+4xYcZp6KLhs6AF lxvhjWbLCE+6UJRLlc/LbCtmRnZlmRcymKl0bp3cFiTI7bsaEcVAuIM8x6ihojMo1J28 AE3zFeN3ZS5pK+ul4ITxxZ29HIgCCdkLVGSTxLx9HE48NpFficVLomWmDEOmzpbzX0hg f9Bw==
X-Gm-Message-State: AOAM531AOx9kk0ow/jlh7LhPCEj9J36fH9Tb6tc7jdYgTHQ0AaCTEXFf d289kooELWLYje8Om/LtIfN38Q==
X-Google-Smtp-Source: ABdhPJy4WUlK6+lM+acZKOkwyQIXDm5RbsZa9kS/774SjiYempgOfa/YbDUh+LYKms3xiDz0GQ/20w==
X-Received: by 2002:ae9:d8c1:: with SMTP id u184mr1269073qkf.372.1622755168844; Thu, 03 Jun 2021 14:19:28 -0700 (PDT)
Received: from smtpclient.apple (c-24-0-149-15.hsd1.nj.comcast.net. [24.0.149.15]) by smtp.gmail.com with ESMTPSA id h2sm2350797qtk.74.2021.06.03.14.19.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jun 2021 14:19:28 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
From: Jonathan Lennox <jonathan.lennox@8x8.com>
In-Reply-To: <162265058467.12641.14507999218364492698@ietfa.amsl.com>
Date: Thu, 3 Jun 2021 17:19:27 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-payload-vp9@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <30E6C68D-2D2B-4120-AB7E-E96F575AA8B3@8x8.com>
References: <162265058467.12641.14507999218364492698@ietfa.amsl.com>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/JKMV41lR7Q6uuft8UtRq91aOfDo>
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 21:19:37 -0000


> 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.