[Cellar] Roman Danyliw's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 07 October 2020 15:52 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>, "Peter B." <pb@das-werkstatt.com>, pb@das-werkstatt.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160208595678.10340.14249512049911790799@ietfa.amsl.com>
Date: Wed, 07 Oct 2020 08:52:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/D9pIZKMDkrrG5HjOpfwsZZd-IWA>
Subject: [Cellar] Roman Danyliw's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-cellar-ffv1-17: Discuss

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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A simple clarification.

Section 6.
   Implementations of the FFV1 codec need to take appropriate security
   considerations into account, as outlined in [RFC4732]

RFC4732 only covers DoS.  A buffer overflow (as described in the subsequent
text of this paragraph) in a codec implementation could have dramatically more
significant consequences for the endpoint (or the services it provides) than a
DoS.  It could potentially lead to arbitrary remote code execution on the
system (barring defensive mitigations provided by sandboxing in the app, OS
execution protections; and/or end-point protection software) which pretty much
enables an attacker to do anything of their choosing on the system.  Please
note that.


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

(Sorry for any confusion with the updated ballot.  I didn't cut-and-paste all
of the text.  COMMENT is the same.  DISCUSS is added.)

Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for
providing the review).

I support Barry Lieba’s Discuss position.

A few comments on the framing of the codec description:

** Section 1.  Is “non-experimental use” the same as production use?

** References.  Why use C89/90 for syntax and C18 for operator precedence? 
Wouldn’t C18 work for both?

** References.

-- Doesn’t Section 4.3.3.2 required [ISO.14496-12.2015] as a normative
reference to parse the "glbl" box in the ConfigurationRecord bitstream?

-- Doesn’t Section 4.3.3.3 required [NUT] as a normative reference to parse the
ConfigurationRecord bitstream?

On the security considerations:

** Section 6.  Per the reference to [RFC4732], which selection is relevant
here? Is it Section 2.1.1?

** Section 6.  The assertions about the security properties of [REFIMPL] don’t
make sense to me in this document.  While it is extremely helpful that there is
a high-quality reference implementation, it’s relevance to this spec isn’t
clear.  This code isn’t normative.  Recommend removal all text after the
paragraph “None of the content carried in FFV1 is intended to be executable”.

[Cellar] Roman Danyliw's Discuss on draft-ietf-ce… Roman Danyliw via Datatracker