Fwd: spoofing and IRIs

FYI, a discussion about security considerations for IRIs.
--
Thomas Roessler, W3C  <tlr@w3.org>







Begin forwarded message:

> From: "Larry Masinter" <LMM@acm.org>
> Date: 2 March 2010 20:06:46 GMT+01:00
> To: "'Maciej Stachowiak'" <mjs@apple.com>
> Cc: <public-iri@w3.org>, <markdavis@google.com>, <michel@suignard.com>
> Subject: RE: spoofing and IRIs
> archived-at: <http://www.w3.org/mid/001501caba3b$83aa8df0$8affa9d0$@org>
> 
> I hope amending “user agents SHOULD NOT rely on visual or perceptual”…
> to “user agents SHOULD NOT rely on users doing visual or perceptual”…. addresses the first concern you raised.
>  
> I agree with your point that UTR#36 as currently organized contains much information that is extraneous to the IRI spoofing issue, and it would be helpful to point those out. But it seems to be the most extensive analysis of the issues, and is more likely to be maintained as Unicode evolved, so I think referencing it is useful. (By cc to the authors listed (Mark Davis and Michel Suignard), I’d like to ask if UTR#36 could be reorganized or the sections annotated t to explicitly call out which sections apply  to IRIs, to IDNA, or have other scope.)
>  
> My intent wasn’t really to summarize TR #36, but really to note that, considering all of the risks noted in UTF#36, that there wasn’t really any way that visual comparison *can* be done safely, and that the “best practice” for mitigating the security risks associated with visual or perceptual comparison or verification is to just not rely on it at all.
>  
> I’m not sure if you agree or disagree with that as an appropriate “Security Considerations” section, but I’d be happy to hear any counter-proposals of how to deal with this messy issue without having to resolve all of the security mitigations before progressing this document.
>  
> My hope is that everyone can agree on an overall strategy for getting work here quickly:   focus the main IRI document on the concrete requirements and syntax and processing rules for IRI, and move any of the more difficult, messier, controversial and evolving best practices issues to other documents that could evolve independently, and on their own schedule.  That’s a general approach to modularizing documents that I’ve tried to take elsewhere.
>  
> Larry
> --
> http://larry.masinter.net
>  
>  
>  
> From: Maciej Stachowiak [mailto:mjs@apple.com] 
> Sent: Sunday, February 28, 2010 10:17 AM
> To: Larry Masinter
> Cc: public-iri@w3.org
> Subject: Re: spoofing and IRIs
>  
>  
> On Feb 27, 2010, at 9:19 PM, Larry Masinter wrote:
> 
> 
> (resending after fixing access problem)
>  
> Right now, the “Security Considerations” section of http://tools.ietf.org/html/draft-ietf-iri-3987bis-00#section-10  contains a relatively short discussion of the issues around spoofing.
>  
> I’d like to replace most of that section with a summary and a pointer to the Unicode Technical Report #36
>  
> http://unicode.org/reports/tr36/tr36-8.html
>  
> which expands the discussion quite a bit.  I think a summary might be the form:
>  
> =============draft============
> There are serious difficulties with  relying on a human to verify that a presentation of an IRI to them  (whether visually or read out loud) is the same as another identifier or is the one intended. These problems exist with ASCII-only URIs (bl00mberg.com vs. bloomberg.com) but are enormously exacerbated when using  the larger character repertoire of Unicode; these problems are elaborated in [UTR#36].  There seems to be little hope of relying on either administrative or technical means to reduce the availability of such exploits, to the extent that user agents SHOULD NOT relying on visual or perceptual comparison or verification of IRIs as any means of validating or assuring safety, correctness or appropriateness of an IRI.
>  
> [UTR#36] also identifies additional security considerations that are applicable to IRIs.
>  
>  ======draft============
>  
>  
> Basically, I want to push the issue of Spoofing in IRIs to another document.
>  
> Thoughts?
>  
> Comments?
>  
> I think there's one piece of your summary that is oddly stated: "... to the extent that user agents SHOULD NOT relying on visual or perceptual comparison or verification of IRIs as any means of validating or assuring safety". User agents don't do any visual comparisons of IRIs directly for their own purposes, they do character-by-character comparisons. The problem is with users themselves, not user agents, doing visual comparisons. Also, while UTR#36 has many specific suggestions for improving IRI security, they are not all for user agents. Some are recommendations for procedures when registering domain names. The UA recommendations do not amount to completely removing the user's reliance on visual comparison, although they may somewhat mitigate the risk of showing the user certain kinds of visually confusable URIs. I'm not sure the recommendations of UTR#36 can be summarized adequately in a short paragraph.
>  
> Regards,
> Maciej
>  
>  
>  
>  
>  
>  
>