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

[Tero Kivinen <[e-mail]>]

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