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

Julian Reschke <julian.reschke@greenbytes.de> Fri, 26 February 2010 13:46 UTC

Return-Path: <julian.reschke@greenbytes.de>
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 51B063A87A6; Fri, 26 Feb 2010 05:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 d2lQqiIa-BLe; Fri, 26 Feb 2010 05:46:02 -0800 (PST)
Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id 0702C3A87A4; Fri, 26 Feb 2010 05:46:01 -0800 (PST)
Received: from [192.168.1.105] (unknown [192.168.1.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id E4F60C4CA98; Fri, 26 Feb 2010 14:48:14 +0100 (CET)
Message-ID: <4B87D118.1090408@greenbytes.de>
Date: Fri, 26 Feb 2010 14:48:08 +0100
From: Julian Reschke <julian.reschke@greenbytes.de>
Organization: greenbytes GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <19335.45416.521059.570426@fireball.kivinen.iki.fi>
In-Reply-To: <19335.45416.521059.570426@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: httpbis-chairs@tools.ietf.org, Graham Klyne <GK@ninebynine.org>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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 13:46:03 -0000

Hi Tero,

On 26.02.2010 12:32, Tero Kivinen wrote:
> 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:

Indeed; that was due to unfortunate timing; the issue was raised before 
LC, but as LC was already requested I didn't have time to resolve it. 
Thus, I noted it as open issue.

> ----------------------------------------------------------------------
> 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.
> ----------------------------------------------------------------------

In the meantime I replied in 
<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01338.html>, 
posting this proposal:

-- snip --
5.  Security Considerations

    The format described in this document makes it possible to transport
    non-ASCII characters, and thus enables character "spoofing"
    scenarios, in which a displayed value appears to be something other
    than it is.

    Furthermore, there are known attack scenarios relating to decoding
    UTF-8.

    See Section 10 of [RFC3629] for more information on both topics.
-- snip --

> 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.

I'm a bit reluctant to add more than I already have. After all, this 
applies to *any* IETF spec that has proper I18N, so, in theory, 
*everything* the IETF does that allows natural language text.

It would be really great if we had a document that summarized common 
security considerations, so that "higher-level" specs could just point 
to individual parts of these.

For the spoofing issue I'm now pointing to RFC 3629 -- do you feel we 
need more?

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782