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

[Julian Reschke <[e-mail]>]

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

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