[UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

Shawn Steele Shawn.Steele at microsoft.com
Mon Mar 13 16:45:09 UTC 2017


The catch (as I understand it) is that bundling is work, and it's easy to just let confusables be sold normally.

I'm also of the opinion that bundling isn't perfect.   In some scripts (Chinese in particular) it can be very hard, there are very subtle differences that are valid words.  There are even all-ascii stuff that can be confused in the right font.

Not against bundling, but "normal" non-technical people have a much bigger problem, homographs are more targeted at us.  Normal folks click on "your.bank.trust.me" and "bank.safe.net" and stuff.  Worse, enterprises make no effort to ensure that they're names aren't strange like that.  My bank has used 3rd party services so that I get mail from "mybank.provider.com" instead of mybank.com.  "real" surveys are really bad for that.  And lots of the time attackers don't even bother, I saw an amazon spoof last week that was just gibberish for the domain name.

The internet won't end if confusables can't be solved.

-Shawn

-----Original Message-----
From: Mark Svancarek 
Sent: Monday, March 13, 2017 6:41 AM
To: nalini.elkins at insidethestack.com; Shawn Steele <Shawn.Steele at microsoft.com>; Richard Merdinger <rmerdinger at godaddy.com>; Edmon Chung <edmon at registry.asia>; UA-discuss at icann.org
Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

FWIW (and to coin a phrase), I'd consider "www.TRÛMP.com" more of a "pun" than a "confusable".  It's evocative of "Trump" but is visually distinct.

-----Original Message-----
From: nalini.elkins at insidethestack.com [mailto:nalini.elkins at insidethestack.com] 
Sent: Monday, March 13, 2017 2:35 PM
To: nalini.elkins at insidethestack.com; Shawn Steele <Shawn.Steele at microsoft.com>; Richard Merdinger <rmerdinger at godaddy.com>; Edmon Chung <edmon at registry.asia>; UA-discuss at icann.org; Mark Svancarek <marksv at microsoft.com>
Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

Sure.

The problem is if you are trying to buy a name for a potential homographic attack or confusion and the original name belongs to someone else.  In fact, is a trade mark of the other person.

I have been doing some very fun work in this space.   I have an algorithm which does permutations of names & we have been working on the homoglyphs.   I have done some initial monitoring to see who has registered what names already.

For example:

www.TRÛMP.com
www.TRÜMP.com

have already been registered & not by our illustrious leader.

Once I get things more figured out, I will set up a server to monitor continously.  One of my guys is working on the homoglyphs, we are not happy with the confusables that others have referred to so we are doing our own.

If you would like to know who has already registered "Microsoft"-ish names from my initial testing, please contact me privately. 

Nalini

--------------------------------------------
On Mon, 3/13/17, Mark Svancarek <marksv at microsoft.com> wrote:

 Subject: RE: [UA-discuss] FW: I-D Action:	draft-klensin-idna-rfc5891bis-00.txt
 To: "nalini.elkins at insidethestack.com" <nalini.elkins at insidethestack.com>, "Shawn Steele" <Shawn.Steele at microsoft.com>, "Richard Merdinger" <rmerdinger at godaddy.com>, "Edmon Chung" <edmon at registry.asia>, "UA-discuss at icann.org" <UA-discuss at icann.org>
 Date: Monday, March 13, 2017, 6:22 AM
 
 To avoid the conflict, I could
 imagine a transaction like:
 
 "Your requested domain name Q has been identified as one  likely to cause user confusions due to its mix of characters  and character sets. (See our Confusables Policy,  here).   As a result, ownership of this  domain name must be bundled with the following additional  domain names:
 X
 Y
 Z
 This bundle of domain names is available for the low price  of $$.
 Unfortunately, we are not able to offer the domain name Q  separately from this bundle. If you are not interested in  this bundle, might we suggest the following alternatives:
 H
 J
 K
 Thanks."
 
 
 -----Original Message-----
 From: nalini.elkins at insidethestack.com
 [mailto:nalini.elkins at insidethestack.com]
 
 Sent: Monday, March 13, 2017 1:35 PM
 To: Shawn Steele <Shawn.Steele at microsoft.com>;  Richard Merdinger <rmerdinger at godaddy.com>;  Edmon Chung <edmon at registry.asia>;  UA-discuss at icann.org;  Mark Svancarek <marksv at microsoft.com>
 Subject: Re: [UA-discuss] FW: I-D Action:
 draft-klensin-idna-rfc5891bis-00.txt
 
 >Pretty much all of the concerns regarding the character  repertoire can be resolved and the registrar level if the  registrars would ensure that they did not allow  registrations of multiple domain variations that >might  confuse their users.  Or if they bundled those  registrations.
 
 There is a potential conflict of interest  here.   Registries want to sell as many  domains as they can as that is how they make money.
 
 Thanks,
 
 Nalini Elkins
 Inside Products, Inc.
 www.insidethestack.com
 (831) 659-8360
 
  
  
  From:
  Shawn
  Steele
  
  Sent:
  ‎3/‎12/‎2017 7:33
  PM
  
  To:
  Richard
  Merdinger;
  Edmon
  Chung;
  Mark Svancarek; UA-discuss at icann.org
  
  Subject:
  RE: [UA-discuss] FW: I-D Action:
  draft-klensin-idna-rfc5891bis-00.txt
  
  
  
  
  
  
  My concern is John’s emphasis on
  creating very restrictive character rule sets.
   
  The most restrictive rules created
  by IDNA2008 have been ignored because of user demand  and  backwards compatibility.  Eg: no-emoji in  labels.  People want emoji, but IDNA2008
   doesn’t permit it.  Part of that is
 compatibility  with the permitted IDNA2003 emoji,  however there has also  been demand for emoji  characters newly added to  Unicode.
   
  I think that it is appropriate to
  remind registrars that they are responsible for  creating  sane rules for their spaces, but it is clear  that users do  not want to be tied to
   the most restrictive demands of IDNA2008.  Implementations appear to be settling on the Unicode  provided idna data and I would much prefer to see the  IETF  standards point to the IDNA character sets  provided by  Unicode (while still encouraging  registrars to
   do sane things that make sense for their  domains).
   
  A good example of something a
  registrar might want to consider could be something  like  ü.  Some spaces may allow ü without much  restriction,  however for .de, .ch, .at, etc.
   it might make sense to recognize that ü has an  alternate  ue spelling and to provide bundling or  blocking of domains  like müller.ch and mueller.ch.  That kind of rule is  very domain/language specific.  Though it is not called  out as some of the bidi rules  are,
   the RFCs allow registrars to implement such a policy  if it  fits their purposes.  Of course many other  behaviors  are called out by the IDNA2008 rules.
   
  Pretty much all of the concerns
  regarding the character repertoire can be resolved and  the  registrar level if the registrars would ensure  that they did  not allow registrations
   of multiple domain variations that might confuse  their  users.  Or if they bundled those  registrations.
   
  -Shawn
   
  
  
  
  From: Richard Merdinger
  [mailto:rmerdinger at godaddy.com]
  
  
  Sent: Saturday, March 11, 2017 11:35 PM
  
  To: Edmon Chung <edmon at registry.asia>;  Mark  Svancarek <marksv at microsoft.com>;  UA-discuss at icann.org
  
  Cc: Shawn Steele <Shawn.Steele at microsoft.com>
  
  Subject: Re: [UA-discuss] FW: I-D Action:
  draft-klensin-idna-rfc5891bis-00.txt
  
  
   
  Agree, thanks for forwarding
  Mark  This was a very cogent statement of affairs  relative to the closing out of known IDN issues (or  our  current inability to do so).
   
  I agree with Edmon in that I think
  the UA effort should strive to be a catalyst  here.
   
  --Rich
   
   
  
  From:
  <ua-discuss-bounces at icann.org>
  on behalf of Edmon Chung <edmon at registry.asia>
  
  Date: Sunday, March 12, 2017 at 7:11 AM
  
  To: 'Mark Svancarek' <marksv at microsoft.com>,  "UA-discuss at icann.org"
  <UA-discuss at icann.org>
  
  Cc: 'Shawn Steele' <Shawn.Steele at microsoft.com>
  
  Subject: Re: [UA-discuss] FW: I-D Action:
  draft-klensin-idna-rfc5891bis-00.txt
  
  
   
  
  
  Thanks for forwarding this
  Mark,
  
  
  This seems to be something useful
  for UA, perhaps we should work with the IDN team at  ICANN  (along with the communities networked from the  LGR work) to  see where we can best support.
  
  
  Edmon
  
  
   
  
  
   
  
  
   
  
  
  
  -----Original Message-----
  
  
  From: 
  ua-discuss-bounces at icann.org
 [mailto:ua-discuss-bounces at icann.org]
  On
  
  
  Behalf Of Mark Svancarek via
  UA-discuss
  
  
  Sent: Sunday, 12 March 2017 12:58
  PM
  
  
  To: 
  UA-discuss at icann.org
  
  
  Cc: Shawn Steele <Shawn.Steele at microsoft.com>
  
  
  Subject: [UA-discuss] FW: I-D
  Action: draft-klensin-idna-rfc5891bis-00.txt
  
  
  FYI, too much stuff from John for
  me to dig into this a.m.
  
  
  -----Original Message-----
  
  
  From: Idna-update [mailto:idna-update-bounces at alvestrand.no]
  On Behalf Of John
  
  
  C Klensin
  
  
  Sent: Saturday, March 11, 2017
  8:25 AM
  
  
  To: 
  idna-update at alvestrand.no
  
  
  Subject: FWD: I-D Action:
  draft-klensin-idna-rfc5891bis-00.txt
  
  
  Hi.
  
  
  For the information of those who
  may be watching this list but not the IETF
  
  
  announcement one...
  
  
  Asmus Freytag and I have started
  to put together a draft that addresses a problem
  
  
  with the IDNA2008 specs,
  specifically that we failed to make the  responsibility  of
  
  
  registries to define code point
  and label acceptability rules that were considerably
  
  
  more narrow (and better understood
  by them) than the full set of labels allowed by
  
  
  RFC 5891-5893.  It
  doesn't actually change anything because that  requirement is in
  
  
  the existing specs; it just makes
  (or tries to make) the requirements painfully clear to
  
  
  those who have been missing or
  misreading them.
  
  
  It also provides an explicit link
  between IDNA2008 requirements and ICANN work on
  
  
  repertoires and label generation
  rules without endorsing that work as more than one
  
  
  thoughtful approach that might be
  examined for either reference or inspiration.
  
  
  Comments (obviously) welcome.
  
  
  For anyone who might wonder, this
  document avoids the more controversial
  
  
  IDNA2008 issues including:
  
  
  * Multiple suggestions that we
  should add emoji, a subset of code points with
  
  
  General Category "So",
  to the list of code
  
  
  points allowed by
  IDNA.   There are many reasons to not do that
  
  
  but it seems clear that, at some
  point, the IETF will need to either document those
  
  
  reasons or make the
  change.  Volunteers to put together or work on a  document
  
  
  would be welcome.
  
  
  * The non-decomposing code point
  problem, formerly (and
  
  
  incorrectly) known as the Hamza
  problem.   There has been no
  
  
  discernable activity on this since
  the IAB Statement and LUCID BOF almost exactly
  
  
  two years ago.  I've
  further updated the working copy of
  draft-klensin-idna-5892upd-
  
  
  unicode70 to cover additional
  cases and issues, but, in part because it is clearly
  
  
  inappropriate for a quick-patch
  individual submission, have been advised to not post
  
  
  it until we have a plan to make
  progress.
  
  
  So far, there is no such plan.
  
  
  * The (IMO, growing) problem of
  multiple and inconsistent specifications for IDNs
  
  
  and IDN handling, with different
  ones being used in different higher-level protocols
  
  
  and areas of the
  Internet.  The use of different specifications and  definitions creates
  
  
  opportunities for user and
  implementer confusion, interoperability difficulties,  domain
  
  
  names that cannot be resolved
  under some circumstances, and various sorts of
  
  
  attacks.
  
  
  The specifications involved
  include IDNA2008, IDNA2003, assorted local  "updates"
  
  
  to IDNA2003 that use versions of
  Stringprep locally updated to assorted versions of
  
  
  Unicode, and the various versions
  of UTR#46.  The latest version of the latter
  
  
  explicitly
  
  
  allows emoji along with other
  symbols.    A few months ago, I
  
  
  suggested to the IAB I18N program
  that a document be produced that at least
  
  
  pointed out the problems
  associated with multiple divergent specifications,  but  the
  
  
  idea got no traction.
  
  
  It appears to me that, although
  almost everyone agrees that IDNs, and well- and
  
  
  clearly-functional IDNs, are
  important, virtually no one is willing to do the hard  work,
  
  
  at least unless they are being
  supported by ICANN (disclosure: I am not) or
  
  
  organizations whose interests lie
  in selling names, preferably as many of them as
  
  
  possible (I have no support from
  any of them either).  Until and unless that  changes,
  
  
  I don't see much prospect for
  getting those other issues addressed in a way that
  
  
  might lead to consensus
  documents.
  
  
        john
  
  
  ---------- Forwarded Message
  ----------
  
  
  Date: Saturday, March 11, 2017
  07:22 -0800
  
  
  From: 
  internet-drafts at ietf.org
  
  
  To: 
  i-d-announce at ietf.org
  
  
  Subject: I-D Action:
  draft-klensin-idna-rfc5891bis-00.txt
  
  
  A New Internet-Draft is available
  from the on-line Internet-Drafts directories.
  
  
          
  Title
  : Internationalized Domain Names in
  
  
  Applications (IDNA): Registry
  Restrictions and Recommendations
  
  
  Authors
  : John C Klensin
  
  
                            
  Asmus Freytag
  
  
         
  Filename        :
  draft-klensin-idna-rfc5891bis-00.txt
  
  
         
  Pages
  : 10
  
  
         
  Date            :
  2017-03-11
  
  
  Abstract:
  
  
      The IDNA
  specifications for internationalized domain names
  
  
  combine    rules
  that determine the labels that are allowed in
  
  
  the DNS
  without    violating the protocol itself  and an
  
  
  assignment of
  responsibility,    consistent with
  earlier
  
  
  specifications, for determining
  the labels    that are allowed
  
  
  in particular
  zones.  Conformance to IDNA
  by    registries and
  
  
  other implementations requires
  both parts.  Experience strongly suggests that  the
  
  
  language describing those
  
  
  responsibility    was
  insufficiently clear to promote safe and
  
  
  interoperable use of
  the    specifications and that more
  details
  
  
  and some specific examples
  would    have been
  helpful.  This
  
  
  specification updates the earlier
  ones to    provide that
  
  
  guidance and to correct some
  technical errors in the descriptions.  It does not  alter
  
  
  the protocols and rules
  
  
  themselves    in
  any way.
  
  
  The IETF datatracker status page
  for this draft is:
  
  
  https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/
  
  
  There's also a htmlized
  version available at:
  
  
  https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00
  
  
  Please note that it may take a
  couple of minutes from the time of submission until
  
  
  the htmlized version and diff are
  available at tools.ietf.org.
  
  
  Internet-Drafts are also available
  by anonymous FTP at:
  
  
  ftp://ftp.ietf.org/internet-drafts/
  
  
  _______________________________________________
  
  
  I-D-Announce mailing list
  
  
  I-D-Announce at ietf.org
  
  
  https://www.ietf.org/mailman/listinfo/i-d-announce
  
  
  Internet-Draft directories: 
  http://www.ietf.org/shadow.html or
  
  
  ftp://ftp.ietf.org/ietf/1shadow-sites.txt
  
  
  ---------- End Forwarded Message
  ----------
  
  
  _______________________________________________
  
  
  Idna-update mailing list
  
  
  Idna-update at alvestrand.no
  
  
  http://www.alvestrand.no/mailman/listinfo/idna-update
  
  
  
   
  
  
   
  
  
  
  
  
 


More information about the UA-discuss mailing list