[secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 13 January 2011 11:50 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B0C3A6AAA; Thu, 13 Jan 2011 03:50:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.256
X-Spam-Level:
X-Spam-Status: No, score=-103.256 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0KJAP8RgO-V; Thu, 13 Jan 2011 03:50:16 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id F14F23A6A9B; Thu, 13 Jan 2011 03:50:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4341C3E4082; Thu, 13 Jan 2011 11:52:35 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1294919555; bh=7mle47ZpEcFMu6nw+Uy2RER4 IpqNRstjuYoji1U6M7M=; b=iEFgHYBHDd8cK/JmEVO2Jktq2FdYyQa7a3SNS42H eyRn7i0+DYziqnM9iS6R8DjIlESQGSFTO2aTfHTb4bpVY7XCuj3X9A68PNC3Li0Y OPv0KGtKS3/U9Mqk/Lz8ivZm5Q6UdEz1xONOVs5MfpdQW15ciMh4BNS3E05tN9kM 4lWmC+uupG292UADAoE00W1L7XR5OtvMWOw2WCd/EkTtHCehKdqxiVzaWbpGpk1Y mzGr0lZwlXdr/RUaum19Y+Ui0p2PCSlwzdFqKnTmNVsrlSL6swT4mK2kgJonHfEx lXWHIDloL+9zFEs6kmHKGza2DlPf1uyZaZYAqft2A7xUYg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8Z6lBcUpXhR3; Thu, 13 Jan 2011 11:52:35 +0000 (GMT)
Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DD0E53E4075; Thu, 13 Jan 2011 11:52:33 +0000 (GMT)
Message-ID: <4D2EE782.3010801@cs.tcd.ie>
Date: Thu, 13 Jan 2011 11:52:34 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mmusic-image-attributes.all@tools.ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 13 Jan 2011 11:50:17 -0000

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

This draft defines a way to ask a sender to use different image
attributes using SDP.

The security considerations says that this doesn't change anything,
but I don't quite agree. A requestor could (accidentally or on
purpose) as for some very large image size or for some kind
of transformation that puts a lot of load on a transcoder, and
that could be part of some DoS attack. (I've actually seen this
bug triggered accidentally in a real system that did more or
less this.)

I'd suggest adding a paragraph to the security considerations
saying that implementations should be wary of this and could
include some sanity checking of inputs or could try to detect
cases where lots of resources are being used and then handle that
somehow. I don't know how that'd be best done, nor whether any
of that should use 2119 type language, but I assume the authors
can figure that out.

Stephen.