phishing in IRIs (was: Re: Using Punicode for host names in IRI -> URI translation; phishing; comparison)

On 2009/11/18 3:56, Larry Masinter wrote:
> These are "strawman" proposals in response to the IAB talk at the IETF meeting last week: knock down if you can.


>   1.  Spoofing
>
> Secondly, there are a number of concerns raised about spoofing. Of course, spoofing is an issue with just ASCII too,
> example.com vs example.corn  being difficult to distinguish, (never mind example.C0M).

I think that this part of the IAB presentation was mainly to make people 
aware of the issues. The IAB presentation did not contain any 
conclusions on this issue, neither in terms of actual directions for 
solutions nor even in terms of "specs have to address this".

> The observation is that there are many ways in which names can be formed for which there is NO visible distinction between what are separate unicode encodings.
>
> The main way I think of addressing these are:
>
>
>   1.  Visual validation of URIs and IRIs is basically *NOT EFFECTIVE*
 > and that user agents *SHOULD NOT USE* visual validation
 > as the primary way of preventing spoofing.

I'm not exactly sure what you mean by "visual validation". Isn't this 
something the user does, rather than the user agent?

 > Other methods for protecting against phishing *MUST* be used.
 > I think we can point to some of the techniques that browsers currently
 > already deploy as alternatives, without making them normative.

There are activities carried out with IRIs where it's absolutely 
inappropriate to require some protection against phishing. So the above 
MUST has to at least be carefully contained.

Also, it should be noticed that the main attack vector for 
phishing/spoofing are IDNs, not IRIs in general. True, there's some 
potential for attacks also in cases such as
http://www.example.net/your_preferred_name/your_hosted_page_here.html

It should also be mentioned that the IDNAbis WG has an explicit 
provision in their charter that phishing in general is out of scope
(from http://www.ietf.org/dyn/wg/charter/idnabis-charter.html):

 >>>>
There are a variety of generally unsolvable problems, notably the
problem of characters that are confusingly similar in appearance (often
known as the "phishing" problem) that are not specifically part of the
scope of the WG although some of the preliminary results of the design
team suggest that the improvements contemplated in the specifications
might mitigate some of the ways in which the current IDNA specifications
can be abused for phishing purposes.
 >>>>

This provision helped the WG to avoid getting into ratholes. I was 
thinking about a similar provision for our charter.

There is one open issue, 
http://www.w3.org/International/iri-edit/#transcodeNFC-103, which (in 
its wider sense) is about when and where to use Unicode normalization. 
The current tendency seems to get rid of the requirement to use NFC is 
certain cases, because this hasn't been implemented.

Other than that, I think phishing/spoofing mainly belongs into the 
security section (where it already is, see 
http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-10).


>   2.  Anyone who prints an IRI on the side of a bus or a matchbook
 > cover has the responsibility of making sure that what they print
 > can be typed in a way that leads to an unambiguous result.
 > Currently this advice only applies to ASCII-only URIs, and the
 > extension to other non-ASCII URIs depends on infrastructure that is > 
NOT currently part of, or mandated by, or appropriate for, the IRI
 > specification.

I don't understand this. Where in RFC 3986 is there such a 
responsibility or advice? In what sense would that advice not apply to 
IRIs? The above point doesn't really have to be made overly explicitly 
in the spec in order to be executed, because people who don't follow it 
will just hurt themselves (the sites they want to be reached won't be 
reached).

 > Unfortunately, the implementation advice on how to generate an
 > unambiguously-enterable IRI depends on technology deployment which
 > HAS NOT YET HAPPENED,

Can you tell us what you are referring to here? I have some ideas for 
what you might mean. In some cases, I may agree, in others, I may disagree.

> and nothing we can specify in the IETF will
 > make it happen sooner.  We can give some advice that will mitigate
 > a few of the problems, but so few that making that advice
 > normative isn't actually helpful.


Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Monday, 23 November 2009 12:12:21 UTC