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

[Andrew Sullivan]

On Wed, Oct 05, 2011 at 09:40:35PM -0700, =JeffH wrote:
> 
> 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) ?

Me too.

> 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.

> What are other potential impedance-mismatch issues that might arise
> that folks might be aware of?

Your example is right.  Unicode has helpfully listed the differences
in these approaches at
http://unicode.org/reports/tr46/#IDNAComparison.  

My feeling about UTS46 is that I understand the motivation, but I
think it's a mistake.  The worry that undergirds it is backward
compatibility.  But IDNA2008 wasn't done because we didn't have
anything else to do; it was done because people saw some real
deficiencies of IDNA2003, and wanted to address those.  As we have
learned with the old-fashioned DNS, the longer you wait the harder it
is to break anything that might be deployed.  Right now we have a very
small deployed base of IDNA2003 users, compared to the burgeoning
potential.  If we nail ourselves to 2003-like behaviour now, we will
have to live with it forever. 

> 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) ?

There's another thing to remember, and that is that the IDNA
Guidelines many TLD registries were working under with IDNA2003 did as
much as possible to emulate the inclusion-based approach IDNA2008
takes.  Of course, none of this works down the tree, anyway, but it's
certainly one thing to take into consideration.

The difficulty zone operators are going to face is that, if client
software just isn't going to update, then you have to support both
2003 and 2008 forms of a label.  There aren't so many of those
examples that it's an insurmountable problem, but it's also more than
2, which makes zone administration policy much more complicated.

> And also which IETF lists might such momentum be discussed on? I
> don't really see anything pertinent on dnsop at ietf.org in the last
> year except for specific discussion of draft-liman-tld-names.

I'm not sure.  In some sense, this isn't a DNSOP problem, because they
focus on operations of the DNS as such.  This isn't that problem: it's
policy, not protocol.  It strikes me that OARC might be a place to
discuss this.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com