Skip to main content

Last Call Review of draft-zern-webp-09
review-zern-webp-09-secdir-lc-kivinen-2022-08-11-00

Request Review of draft-zern-webp
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-09-01
Requested 2022-08-04
Authors James Zern , Pascal Massimino , Jyrki Alakuijala
I-D last updated 2022-08-11
Completed reviews Secdir Last Call review of -13 by Tero Kivinen (diff)
Artart Last Call review of -03 by Henry S. Thompson (diff)
Genart Last Call review of -03 by Thomas Fossati (diff)
Opsdir Last Call review of -05 by Tim Chown (diff)
Secdir Last Call review of -04 by Tero Kivinen (diff)
Secdir Last Call review of -09 by Tero Kivinen (diff)
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-zern-webp by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/GAFrFqqyEsec7Gai0iJvFHMnpNk
Reviewed revision 09 (document currently at 15)
Result Has issues
Completed 2022-08-11
review-zern-webp-09-secdir-lc-kivinen-2022-08-11-00
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.