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

[Graham Klyne <[e-mail]>]

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

Tero Kivinen wrote:
> 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.