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
>> 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
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.
More information about the Idna-update