identical-glyph homographs

Thu Jul 28 21:45:16 UTC 2005

> Let me repeat my other argument: Users don't use domain names
> in trust assessments. 

I strongly disagree with this and other arguments that it's just "bad
PR". I think we're off in theory-land. There are 2 critical requirements
on the end-user side that make SSL work. Whether we like it or not, both
require some level of intelligence:
 1) Users can't ignore browser certificate warnings (i.e. look for the
padlock)
 2) Users have to eyeball the URL to ensure they're at the official web
company site.
	2a) Users have to know what the official company URL is in the
first place.

You may not like the existence of the above 2 rules, and we can argue
about how often people pay attention to them, how feasible they are, but
they are nonetheless a reality. Even the savviest of IT people can only
click on the padlock, verify the cert is signed by a root authority
(which it would be), check that the domain matches (it would), and hope
it's secure -- this isn't just a "dumb user" issue. None of "us" could
tell the difference if homographs were in place (unless you expect every
application/developer to be as smart as Mozilla is).

So, if you allow homographs, you have to add another rule to the chain:

  3) All URLs for trusted sites must be hand-typed in the browser. All
links to SSL sites are never to be trusted.

You can make the case that this should be done, is acceptable, you don't
mind it, etc., but it's clearly an additional link in the security
architecture that wasn't previously necessary and, therefore, not just a
bunch of random PR. Users are already the weak link; counting on them
for yet another thing just doesn't ring true as a good idea.

Bottom line: This is a real issue that reduces the *practical* security
of SSL, which is why there's an IAB group dedicated to it.

Counterpoints:
 - "But users might think 'ebay.com' and 'ebay-security.com' are the
same thing."
	That's unrelated; it's a given that you have to know what the
company URL is in the first place. There's no avoiding that existing
requirement (see 2a above).

 - "There are lots of other browser hacks out there."
	So what? That doesn't justify approving a new global DNS
standard that permits yet another security hole in SSL/PKI. We should be
working to avoid security risks, not approving them in RFCs.

 - "Only the TLDs are protected."
	That's already the case with the way cert's are issued (e.g. you
can go register "ebay.stealyourcreditcard.cx" and get a cert) ... old
news.

Todd Vierling's page is a great example:
http://www.duh.org/homographs.cgi

... and I'm going to go join the IAB-IDN mailing list:
http://lists.paf.se/cgi/listinfo/iab-idn

-Jason

-- 
Jason Sloderbeck 
Positive Networks 
jason at positivenetworks.net