IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec

John C Klensin klensin at jck.com
Fri Sep 30 21:31:05 CEST 2011



--On Friday, September 30, 2011 15:12 -0400 Andrew Sullivan
<ajs at anvilwalrusden.com> wrote:

> On Fri, Sep 30, 2011 at 12:58:56PM -0600, Peter Saint-Andre
> wrote:
>> 
>> Because it seems that most or all of the browsers implement
>> IDNA2003 but have no plans to migrate to IDNA2008.
> 
> Really?  Or is this rather "plan to implement IDNA2008 +
> UTS46"?  The latter is a mapping that breaks some features of
> IDNA2008, but doesn't break everything.

And, depending on what options of UTS46 are chosen, it can be
very hard to tell an IDNA2008 + UTS46 implementation from an
IDNA2003 one by external black-box testing.

> AFAICT, ICANN's current IDN TLD plans, as well as the IDN
> Implementation Guidelines currently out for public comment,
> depend on IDNA2008.  If no browser is actually going to
> implement IDNA2008, then we have a serious mismatch between
> the publishing side and the consuming side, and perhaps policy
> needs to be re-examined.

Conversely, to the degree to which ICANN's plans evolve in the
direction of permitting distinctive treatment (not "discard
character") to ZWJ and/or ZWNJ, browsers that continue to
discard those characters may be writing off a significant number
of users.  Whatever the plans may or may not be, persuasive
commercial pressures could easily arise to get that behavior
changed.

One other observation:  with new locally-tuned  browsers showing
up in various places (including this week's announcement of a
brand-new browser from Amazon), broad statements about what
"all" browsers do ought to be inherently suspicious.

   john



More information about the Idna-update mailing list