Re: Some issues with the IRI document [NFCsecurity-09]

Hello Simon,

I have looked at your issue again, and found a way to fit it into
the current draft. In the security section, there currently is
a paragraph saying:

 >>>>
    Spoofing can occur for various reasons.  A first reason is that
    normalization expectations of a user or actual normalization when
    entering an IRI do not match the normalization used on the server
    side.  Conceptually, this is no different from the problems
    surrounding the use of case-insensitive web servers.  For example, a
    popular web page with a mixed case name (http://big.site/
    PopularPage.html) might be "spoofed" by someone who is able to create
    http://big.site/popularpage.html.  However, the introduction of
    character normalization, and of additional mappings for user
    convenience, may increase the chance for spoofing.
 >>>>

I have appended this to:

 >>>>
    Spoofing can occur for various reasons.  A first reason is that
    normalization expectations of a user or actual normalization when
    entering an IRI, or when transcoding an IRI from a legacy encoding,
    do not match the normalization used on the server side.
    Conceptually, this is no different from the problems surrounding the
    use of case-insensitive web servers.  For example, a popular web page
    with a mixed case name (http://big.site/PopularPage.html) might be
    "spoofed" by someone who is able to create http://big.site/
    popularpage.html.  However, the introduction of character
    normalization, and of additional mappings for user convenience, may
    increase the chance for spoofing.  Protocols and servers that allow
    the creation of resources with unnormalized names, and resources with
    names that are not normalized, are particularly vulnerable to such
    attacks.  This is an inherent security problem of the relevant
    protocol, server, or resource, and not specific to IRIs, but
    mentioned here for completeness.
 >>>>

As I have explained earlier, I still consider this a security issue
much more for the particular protocol or setup than for IRIs per se,
and have said so.

I hope this addresses your concerns. I am tentatively closing this
issue, but any comments or suggestions for improvement are welcome.


Regards,    Martin.


At 00:09 03/04/17 +0200, Simon Josefsson wrote:

>Martin Duerst <duerst@w3.org> writes:
>
> > NFC is only required in the current draft when encoding something
> > from e.g. the side of a bus, or when transcoding it from a non-
> > Unicode encoding. This is only to provide a base level of
> > predictability.
>
>Section 2.4 says "IRIs SHOULD be created using Normalization Form C
>(NFC)."  I don't interprete that to only apply to the scenarios you
>mention, rather it seem to imply that whenever a IRI is created, by
>whatever process, NFC should be used.  Perhaps it can be clarified?
>
> > Still indeed this could lead to security problems with the
> > mechanisms you describe above, if there are two users that have user
> > names that only differ in normalization. But it would seem to me
> > that in this case, the security issue comes from these mechanisms
> > (or the actual use with these specific user names) rather than from
> > IRIs.
>
>If this is so, I believe the IRI security considerations should
>mention this so that people can be aware of it, and abstain from
>deploying IRIs in systems that behave in this way, since doing so
>would introduce problems.  Perhaps some properly worded text could
>be derived from the following strawman?
>
>    Whenever fields of an IRI are normalized, the octet representation
>    is modified.  While this is unavoidable if ambiguities are to be
>    resolved, it can raise security issues in some situations.  In
>    particular, if a iuserinfo field is normalized, a security protocol
>    expecting a certain byte sequence as a username may receive a
>    different one.  This can lead to interoperability failures, but
>    also more serious failures in systems, e.g. when the system
>    performs authorization based on the username.
>
>Thanks.

Received on Thursday, 26 June 2003 16:45:49 UTC