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
- [secdir] Review of draft-reschke-rfc2231-in-http-… Tero Kivinen
- Re: [secdir] Review of draft-reschke-rfc2231-in-h… Julian Reschke
- Re: [secdir] Review of draft-reschke-rfc2231-in-h… Tero Kivinen
- Re: [secdir] Review of draft-reschke-rfc2231-in-h… Julian Reschke
- Re: [secdir] Review of draft-reschke-rfc2231-in-h… Graham Klyne
- Re: [secdir] Review of draft-reschke-rfc2231-in-h… Tero Kivinen