IDNA 2008 security

[John C Klensin]

--On Tuesday, 02 December, 2008 08:59 +0100 Stephane Bortzmeyer
<bortzmeyer at nic.fr> wrote:

>...
>> 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 was a right decision: most real-world phishing (and I see
> a lot of phishing reports) make no attempt to produce
> confusable URLs, probably because most users do not check the
> URL (or do not understand the naming hierarchy so
> paypal.example.com looks like paypal.com for them).
> 
> The last phishing report I saw this morning was not even using
> a domain name and advertised an URL with an embedded IP
> address.

I have actually been astonished that more browser vendors are
not doing an explicit check against an apparent URL in text and
the actual URL in the aref and generating a warning.   In other
words, 
<a
href="http://badguy.example.com/">http://goodguy.example.com/</a>
would trigger a loud warning, as would
<a
href="http://goodguy.example.com.badguy.example.net/">http://goodguy.example.com/</a>
and
<a href="http://10.0.0.1/">http://goodguy.example.com/</a>

That might move the phishers to
<a href="http://badguy.example.com/">Click here</a>
which would presumably not produce an explicit warning, but that
would at least provide all but the most clueless of users a hint
that looking at the links would be a good idea.   IMO, this
would be a help, although the problem of protecting fools from
their follies is clearly unsolvable.  

That sort of mechanism mostly has nothing to do with IDNA.
However, were it adopted, the elimination of mapping rules in
IDNA2003 and the isomorphism of U-labels and A-labels would make
the comparison and testing operations slightly easier for the
browsers to get right (e.g., while
<a
href="http://A-label-form.example.com/">http://U-label-form.example.com/</a>
would still require that an IDNA-aware browser convert the
U-label to an A-label to make the test, use of U-labels in both
strings might not (depending on the browser's assumptions about
IDNA2008 versus IDNA2003 use, whether it wanted to make a
comparison on the U-labels and convert to A-label form only if
that failed, etc.).

But I see this as a small but possibly useful side-effect of
IDNA2008, certainly not a driving design goal.  And, if
implementations don't do the test and warning, or lusers ignore
it, it makes no different which version of IDNA is being used.

     john