[secdir] Secdir last call review of draft-zern-webp-09

Tero Kivinen via Datatracker <noreply@ietf.org> Thu, 11 August 2022 23:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7CAC159496; Thu, 11 Aug 2022 16:39:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tero Kivinen via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-zern-webp.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166026114729.4411.10996813202205081508@ietfa.amsl.com>
Reply-To: Tero Kivinen <kivinen@iki.fi>
Date: Thu, 11 Aug 2022 16:39:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/GAFrFqqyEsec7Gai0iJvFHMnpNk>
Subject: [secdir] Secdir last call review of draft-zern-webp-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2022 23:39:07 -0000

Reviewer: Tero Kivinen
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

In my previous review I listed lots of new possible security concerns that might
apply for graphic libraries, and those were added to the security considerations
section, but what was left out was the text I proposed to say that current 
graphics file format libraries have very important role in the security, as 
so many applications takes images from the untrusted sources and shows them 
on the screen, so writing graphics format libraries should require similar 
security sensitive programming methods than cryptographic libraries etc.

I think adding text in the security considerations section warning stating 
something like this might be needed:

  As graphics file format libraries are used in so many places and used in
  ways where they often take inputs from unknown and perhaps unsafe source, 
  and where there can be severe security issues both on clients (web 
  browsers, email clients) and servers (for example when automatically 
  converting uploaded images from one format to another format on servers),
  the implementations of the graphic file format libraries needs to be 
  written in a way that considers security as one of the primary goals of
  the library, perhaps even before the speed of the decompression or the
  compression efficiency of the generated file.