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

Julian Reschke <> Fri, 26 February 2010 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51B063A87A6; Fri, 26 Feb 2010 05:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d2lQqiIa-BLe; Fri, 26 Feb 2010 05:46:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0702C3A87A4; Fri, 26 Feb 2010 05:46:01 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id E4F60C4CA98; Fri, 26 Feb 2010 14:48:14 +0100 (CET)
Message-ID: <>
Date: Fri, 26 Feb 2010 14:48:08 +0100
From: Julian Reschke <>
Organization: greenbytes GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20060516 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Tero Kivinen <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc:, Graham Klyne <>,,
Subject: Re: [secdir] Review of draft-reschke-rfc2231-in-http-10.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
>     <
>     msg01329.html>
> (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 
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

    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