[secdir] Review of draft-reschke-rfc2231-in-http-10.txt

Tero Kivinen <kivinen@iki.fi> Fri, 26 February 2010 11:30 UTC

Return-Path: <kivinen@iki.fi>
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 D982328C15D; Fri, 26 Feb 2010 03:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level:
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599]
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 r47Lm+QdX6ZI; Fri, 26 Feb 2010 03:30:53 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 68F4D28C159; Fri, 26 Feb 2010 03:30:50 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o1QBWv6r009112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Feb 2010 13:32:57 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o1QBWume015791; Fri, 26 Feb 2010 13:32:56 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19335.45416.521059.570426@fireball.kivinen.iki.fi>
Date: Fri, 26 Feb 2010 13:32:56 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 98 min
Cc: httpbis-chairs@tools.ietf.org, julian.reschke@greenbytes.de
Subject: [secdir] Review of draft-reschke-rfc2231-in-http-10.txt
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: Fri, 26 Feb 2010 11:30:55 -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.  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 defines how http-header field parameters can use
characters outside the ISO-8859-1 character set. The security
considerations section says:

----------------------------------------------------------------------
5.  Security Considerations

   This document does not discuss security issues and is not believed to
   raise any security issues not already endemic in HTTP.
----------------------------------------------------------------------

but already the appendix D, Open issues section lists:

----------------------------------------------------------------------
D.5.  i18n-spoofing

   In Section 5:

   Type: change

   <http://www.ietf.org/mail-archive/web/apps-discuss/current/
   msg01329.html>

   GK@ninebynine.org (2010-02-20): I note that the security
   considerations section says nothing about possible character
   "spoofing" - i.e. making a displayed prompt or value appear to be
   something other than it is.  E.g.  Non-ASCII characters have been
   used to set up exploits involving dodgy URIs that may appear to a
   user to be legitimate.
----------------------------------------------------------------------

I agree on this comment, and the security consideration section should
include text about the ability to character spoofing. Also as the
parameters can include different texts for different languages that
also offers another form of spoofing, for example the example the
title parameter used in the headers could include different titles for
different languages which could affect the way the user interprets it.

As this document does not define any specific parameters, the actual
documents defining parameters using this format specified here should
include text about whether those spoofing attacks are possible and/or
meaningful. Having some generic text in this document explaining the
possible attacks, would make sure those documents include the text
needed. 
-- 
kivinen@iki.fi