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

[Julian Reschke <[e-mail]>]

On 01.03.2010 13:52, Tero Kivinen wrote:
> ...
> 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.
> ...

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

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

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

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