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. This document request webp image format media registration and its security considerations section do mention some of the security issues (buffer overruns and uninitialized data usage). Unfortunately graphics libraries have really bad track record for security, simple search lists about 200-300 CVEs for all widely used graphics formats (jpeg, png, gif), and even some for webp already (for which there is reference in security considerations section). Those issues include integer overflows, resource exhaustion of memory and other resources (file descriptors etc), extended resource usage (very long running time), out-of-bounds writes for both to heap and stack, null pointer references, very large image sizes, zero image sizes and zero width and/or height images, information leaks from the decoder (memory layout, obtaining potentially sensitive information), arbitrary memory writes, memory corruptions etc. As graphics libraries are used in so many places and used in ways where they can cause 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 security issues in them are widespread, i.e., not only limited to the image processing applications themselves. Adding the attack surface even more by adding yet another graphics format with new libraries will make situation even worse. Also the traditionally graphics libraries have not been written as being security sensitive, but in the modern systems they are as integral to the security than the crypto libraries etc. Adding bit more warnings about those issues to the security considerations section would be useful. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
