wrt IDNA2003->IDNA2008 transitionn (was: IDN processing-related, security considerations for draft-ietf-websec-strict-transport-sec)

Yedidyah Bar-David didi at isoc.org.il
Thu Oct 6 11:06:32 CEST 2011

Hi all,

I am a sysadmin in ISOC-IL, the .il ccTLD operator. I've been lurking
here for several years now, and IIRC this is my first post.

On Wed, Oct 05, 2011 at 09:40:35PM -0700, =JeffH wrote:
> Adam Barth said:
> >
> > On Fri, Sep 30, 2011 at 1:02 PM, =JeffH <Jeff.Hodges at kingsmountain.com> wrote:
> >> Adam Barth <ietf at adambarth.com> said:
> >>> More concretely, I can tell you that Chrome plans to continue to
> >>> implement IDNA2003 for the foreseeable future.
> >>
> >> Does that mean just Chrome itself, or Webkit as a whole (and thus having
> >> implications for all webkit-based browsers) ?
> >
> > Different WebKit ports can make different choices in this regard.
> > However, I don't know of any major ports choosing anything other than
> > IDNA2003.
> So I'm wondering how well this is going to work out if the DNS
> registry & registrar world migrates to IDNA2008 per se (i.e. with or
> without RFC5895, but without UTS#46) ?
> If I understand correctly, one example issue is:
>   If some DNS registries do not allow Esszet and Final Sigma (Latin
>   small letter sharp S and Greek small final sigma) to be registered,
>   and if some applications that use DNS are applying IDNA2003, then some
>   lookups will make it appear that, for example, Esszet HAS been registered
>   because of the conversion to "ss" (assuming a target using the "ss"
>   form actually exists). And of course, the bit about having a target
>   actually exist could be conveniently arranged by phishers.

Some browser vendors have tables that hopefully prevent some of these
attack attempts. A browser that knows that a specific TLD does not
allow Esszet will hopefully show this somehow when a user clicks such
a link. One list I know of is:
It might be helpful to create somewhere a list of such and related

> What are other potential impedance-mismatch issues that might arise
> that folks might be aware of?
> Thus I'm curious about what the momentum is like for ccTLDs and
> gTLDs to support IDNA and which version thereof ( IDNA2008, IDNA2008
> + RFC5895, IDNA2008 + UTS46, or IDNA2003) ?

We allow registration of some specific IDNA2008-only domain names -
specifically, those having Hebrew characters and ending with
a (latin) digit. E.g. ABC12.co.il (with "ABC" being Hebrew letters).

In our registration rules we mention neither IDNA2003 nor IDNA2008,
but simply write our own rules, which are (intended to be) a very small
subset of IDNA2008: http://isoc.org.il/domains/il-domain-rules.html
When people do request registration of such IDNA2008-only names, we make
them aware of the current situation, in which (almost?) no browsers allow
trivial use of such names. We obviously hope that this situation will
change with the proliferation of IDNA2008 browsers.

As far as I understand, the differences between the various versions
above (IDNA2008, IDNA2008+RFC5895, UTS46) are irrelevant for the subset
we allow. If I am wrong, I'll appreciate more input about this. The only
thing I can think of is registration of capital latin letters, which we
do not allow. So one might say we support strict IDNA2008.

Looking at IANA's "Repository of IDN Practices" at:
(which is somewhat hard to find by searching google for relevant terms,
not sure why), it seems that very few registries support RTL languages
and/or updated their policy after IDNA2008 was published as RFCs.

More information about the Idna-update mailing list