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

[Tero Kivinen <[e-mail]>]

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>

   [e-mail] (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. 
-- 
[e-mail]