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

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Mar 2010 14:52:56 +0200

Julian Reschke writes:
> -- 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 think that text adequately covers non-ASCII characters issues. 

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

Yes, but the impact of them is different. For example it does not
really matter if the filename parameters having different languages
differ, but there might be parameters where this really matters.

As this document does not define any exact parameters, it might be
enough to comment something like that "This document specifies way to
transport multiple language variants for parameters, and such use
might allow spoofing attacks, where different language versions of the
same parameters do not match. Whether this attack is useful as an
attack depends on the parameter specified."

This way the one writing documents specifying parameters allowing
multiple languages and specifying some kind processing on them will
think whether this attack affects them or not.

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

Such document would probably be so long that it would not be that
useful. I think listing exact security considerations specific for
this document in the security considerations section is better,
altough for background information pointing to another document (like
RFC 3629) is enough.

> For the spoofing issue I'm now pointing to RFC 3629 -- do you feel we 
> need more?

I am not really sure for what kind of parameters the different
language versions are used, so I cannot really comment whether there
can be security issues because of them.

If you are sure there cannot be any security issues because of them,
then you should say so. If you do do not know, then it is better to
mention here to make those who use them to think about the security
issues they might raise. 
-- 
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Mar 2010 18:33:49 +0100

On 01.03.2010 13:52, Tero Kivinen wrote:
> ...
> ...

Ack.

I'm tracking this at 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html#rfc.issue.multiple-inst-spoofing>.

For now I have modified the Sec Considerations to:

-- snip --

    In addition, this document specifies a way to transport multiple
    language variants for a single parameter, and such use might allow
    spoofing attacks, where different language versions of the same
    parameter are not equivalent.  Whether this attack is useful as an
    attack depends on the parameter specified.
-- snip --

Please let me know whether this works for you (and thanks for the 
concrete proposal).

> altough for background information pointing to another document (like

Of course it would be long :-). But by giving it the right granularity 
other specs could just refer to the proper part.

For instance, do we really want all HTTP related specs have *different* 
security considerations about DNS spoofing, poisoning, XSS, etc? Maybe 
something to be discussed in Anaheim (Alexey?).

 > ...

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Graham Klyne <[email-masked]>
Date: Mon, 01 Mar 2010 19:34:52 +0000

For information:

Larry Masinter recently suggested replacing some similar text in the IRI 
specification with a reference to a Unicode report:

http://lists.w3.org/Archives/Public/www-tag/2010Feb/0175.html

#g
--

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Mar 2010 11:18:50 +0200

> Please let me know whether this works for you (and thanks for the 

Yes, that text works for me.
-- 
[email-masked]