Subject: Re: [iucg] IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec

From: JFC Morfin <[email-masked]>
Date: Sun, 09 Oct 2011 03:18:56 +0200

At 17:47 08/10/2011, Gervase Markham wrote:
>On 30/09/11 19:58, Peter Saint-Andre wrote:
> > Because it seems that most or all of the browsers implement IDNA2003 but
> > have no plans to migrate to IDNA2008.
>
>Mozilla wishes, as far as I know, to migrate to IDNA2008, but we are
>blocked by two problems:
>
>- a licensing issue with the library we want to use
>- manpower

Gervase,

there are two complementary types of support IDNA2008 which only 
specifies the network side behavior:

- through the IDNA current architectural framework: in this case you 
have to use a library and implement it.
- through the IUI (Intelligent Use Interface) supporting a unified 
IDNA service: in that case one only have to make sure that what is 
typed in by the user is what is passed to the IUI ML-DNS resolver. 
IDNA2008 compliance and punycode conversion is one of its tasks.

At this stage, the IUI architecture well understood and partly 
disclosed at the IUCG site. The delay we meet with the ML-DNS testing 
are also due to man power, but most of all to the evaluation, test 
and choice of the components of an IUI quasi universal prototype 
middleware. Until now, I did bet on an IETF efficiency and waited for 
the IAB to acknowledge the architectural implications of IDNA2008. 
Jeff Hodges's questions shown I was wrong. So, I am going to work 
more seriously these coming mounths on an IUI prototype and on an 
organization to document its standards.

The only thing I would need from Firefox would be an easy options menu choice :

- enable stringprep+punycode
- enable punycode after IDNA2008 filtering.
- filter non-ASCII entries
- disable any modification of the user entry.

Best
jfc