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

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Feb 2010 13:32:56 +0200

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>

   [email-masked] (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. 
-- 
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Feb 2010 14:48:08 +0100

Hi Tero,

> considerations section says:

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.

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

-- snip --

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

> possible attacks, would make sure those documents include the text

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