Subject: Re: IDNA and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT))

From: Nico Williams <[email-masked]>
Date: Mon, 26 Jan 2015 03:12:30 -0600

As far as I'm concerned it's clear that the correct way to handle these
cases is: as confusables.  Is this wrong?

Nick
--

---

From: Asmus Freytag <[email-masked]>
Date: Mon, 26 Jan 2015 07:35:42 -0800

On 1/26/2015 1:12 AM, Nico Williams wrote:
> As far as I'm concerned it's clear that the correct way to handle 
> these cases is: as confusables.  Is this wrong?
>
> Nick
> -- 

Nico,

I basically agree with you.

I'm making a further distinction between confusables by accident and 
confusables by intent, and am advocating that the latter can be handled 
more explicitly. But basically, yes.

A./

---

From: Nico Williams <[email-masked]>
Date: Mon, 26 Jan 2015 12:13:09 -0600

On Mon, Jan 26, 2015 at 07:35:42AM -0800, Asmus Freytag wrote:
> confusables by intent, and am advocating that the latter can be
> handled more explicitly. But basically, yes.

I'm not sure that the cause of the confusability makes any difference.
It's there.  Once it's there we have to deal.

The details of how a confusable came about are certainly interesting,
but they don't really matter to how we handle them, right?

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Jan 2015 18:08:40 -0500

--On Monday, January 26, 2015 12:13 -0600 Nico Williams
<[email-masked]> wrote:

>> > As far as I'm concerned it's clear that the correct way to
>> > handle these cases is: as confusables.  Is this wrong?
>> 
>> I'm making a further distinction between confusables by
>> accident and confusables by intent, and am advocating that
>> the latter can be handled more explicitly. But basically, yes.
> 
> I'm not sure that the cause of the confusability makes any
> difference. It's there.  Once it's there we have to deal.

I don't know if this is related to what Asmus was thinking, but
I think there are two kinds of intent.  One is intent in the
Unicode coding, where a deliberate decision was made to assign
different code points to glyphically-identical characters
("homographs" or "homoglyphs") within the same script.  For that
case, we, or at least UTC, presumably know what the characters
are and could, at least in principle, make a list of them or
assign a special property value to them.  In the grand scheme of
things, they should be very easy to identify even if what to do
once they are identified might be controversial.   For example,
if the only tool we had was to ban one or another code point or
combining sequence of a "confusable" pair, it may not be obvious
which one to prohibit.   Taking U+08A1 as an example because it
is the case that started this, if one were not constrained by
stability rules or the like, it would not be clear whether it
would be better to allow it (because it obeys the rules that
Asus summarized in yesterday afternoon's note and is more
compact) or the combining sequence \u0628\u0654 (because it is
more likely to be used/ expected/ keyed in by Arabic speakers or
users of languages written in Perso-Arabic variations and there
are many more people in those two groups than there are writers
of Fula in Arabic script).

The other sort of intent involves a would-be attacker
deliberately trying to create confusion, to mislead the user, or
to create distrust of the identifier system, in the IDNA case,
the DNS or IDNs generally.  There is nothing accidental about
those cases and they are difficult precisely because none of the
fine distinctions we are making about the differences among "the
same glyph (grapheme cluster)", "the same (or different)
abstract character", and "things that look alike under some set
of circumstances that an attacker might be able to control or
exploit".

And then there are accidents, either of cross-script
similarities or identities (because of historical copying, some
may not really be accidental) or of user perception because of
combinations of appearance of the characters and user
perceptions.

I think the first of these is (or should be) much easier to
handle in a systematic way than the other two, but that, if we
want internationalized identifiers, we'd better be able to do
better with the others than trying to educate users to be
really, really, careful, perhaps to the point of paranoia ... 

--On Monday, January 26, 2015 12:09 -0600 Nico Williams
<[email-masked]> wrote:

>...
>> Yes, indeed. Which is why, for years, this was a requirement
>> of IDNA enablement in Firefox. Only the proliferation of
>> registries put an end to our enforcement of that policy
>> programmatically. We (or at least, I) now intend to enforce
>> it via the media if there is ever a problem caused by a
>> registry allowing one of its customers to attack another one
>> by registering a homograph.
> 
> Right, if a registry screws this up, their reputation has to
> suffer.
> 
> (The same goes for CAs, no?  Though of course DNS has to come
> first.)

While I'm certainly in favor of shaming evildoers, keep two
things in mind.  First, while the number of distinct registry
operators is much smaller, the number of TLDs may soon exceed
the number of active CAs.  The total number of zones and zone
administrators probably deserves terms like "astronomical".
Perhaps unlike the CA environment (or perhaps not), there is a
fairly impressive history of registrars and retailers who are
willing to delegate obviously-deceptive names if doing so
improves their bottom line even slightly and who are quite happy
to hide the names and contact information of their customers.
If we don't do the best we can to control that situation, it
more or less invites regulator intervention that could fragment
the DNS namespace or worse.  I certainly have days, and assume
that Gerv does too, when I'd be delighted to see those
regulators and their law enforcement associates show up.  But
history suggests that, when they do, they are likely to be
heavy-handed enough to be very bad for the DNS and the Internet.

    john

   john

> 
> The details of how a confusable came about are certainly
> interesting, but they don't really matter to how we handle
> them, right?
> 
> Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 26 Jan 2015 18:45:29 -0600

> administrators probably deserves terms like "astronomical".

Meh.  There may be many new TLDs, but they are looking rather empty and
insignificant.  We'll see how it goes for them, but I'm betting on
'badly'.  In any case: it doesn't matter.  What matters isn't how many
of these there are, but that the number of unconstrained CAs be low
(which DNS achieves, while the WebPKI does not).

---

From: Nico Williams <[email-masked]>
Date: Mon, 26 Jan 2015 18:50:20 -0600

> (which DNS achieves, while the WebPKI does not).

As a corollary: more competition by [constrained] TLDs is good because
if -say- com. allows too many embarrassing confusable domains to be
registered, leading to noticeable and noticed phishing attacks, then
perhaps more [new] business will move off it and onto new TLDs.

I'm not concerned with this.

I'm concerned with making sure that registries have the tools they need
to detect and prevent confusable domain registrations [by different
owners], and that would-be registrants have the tools they need to
determine the confusable risk of their would-be domainnames.  As to
this, is UTR#39 enough, yes or no?

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 27 Jan 2015 02:11:42 -0000

>the number of active CAs. ...

For the new gTLDs, ICANN has a long set of rules which boil down to
pick a set of script tables and only allow names in a single script.
Having looked a a lot of the tables, I can report that almost without
excpetion, if they allow any IDNs at all, the applicants picked a
small set of scripts and copied the tables from existing gTLDs.

The ones from countries that use Roman scripts tend to have a handful
of Roman tables like Spanish, French and English, the ones from
Cyrillic countries have Russian and maybe one more like Serbian, the
ones from China have traditional and simplified, the ones from Korea
have the same table as .kr, and the ones from Japan have the same
table as .jp.  The lack of creativity is quite heartening.

Of course, you can put any crud in the 3LD and below, but that's
always been true.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Jan 2015 03:38:16 +0000

> Of course, you can put any crud in the 3LD and below, but that's

Indeed.  For example, Safari seems to be based on IDNA 2003, and
displays

    xn--ls8h.example.com

(U+1F4A9) as

    <glyph for smiling pile of poo>.example.com

while Firefox and Chrome manage to avoid displaying that glyph,
leaving the domain in Punycode form.

-- 
	Viktor.

---

From: Shawn Steele <[email-masked]>
Date: Tue, 27 Jan 2015 01:17:10 +0000

> if -say- com. allows too many embarrassing confusable domains to be registered, 
> leading to noticeable and noticed phishing attacks, 

I think that underestimates the users....  But "does it matter"?

I've received 4 emails today that made it through whatever spam filters for whatever reason.  All 4 of them seemed to provide the opportunity for phishing attacks, and 0 of them leveraged IDN.  For that matter, they weren't even trying to be that clever with the ASCII paths.

I think the impact on phishing and confusables may be embarrassing perhaps, but don't have much true impact on security.  How many times have you mistyped a URL and ended up somewhere else?  Often with advertising and stuff trying to make a few cents off of the target URL typos?  

Too many companies send emails from "[email-masked]" (totally random) or send you to "company.orderprocessing.example.com" and expect you to complete a link.  So phishing stuff with @secure.com is going to succeed.  They don't need confusable.  (I've even seen papers that suggest that scammers sometimes prefer obvious traps because they really want to get the gullible folks - obvious bad URLs could filter those out.)

-Shawn

---

From: Mark Davis ☕️ <[email-masked]>
Date: Tue, 27 Jan 2015 13:13:20 +0100

There is a significant difference between (a) how a browser chooses to
display a URL and (b) whether it accepts and goes to the expected page.
Punycode in (a) is often triggered by whether the browser is trying to
indicate that there is something odd about the URL.

For example, http://xn--eih.blogspot.ch/ displays for me currently on the
Mac as the following. (I don't have a Windows 8 machine handy.)

Note that Chrome (Canary) displays as punycode, but actually goes to the
expected page.

*Firefox*

*Safari*

*Chrome Canary*

Mark <https://google.com/+MarkDavis>

*— Il meglio è l’inimico del bene —*