Standards and localization (was Dot-mapping)

[Erik van der Poel]

Gervase and John,

Maybe I should not have focussed on the spoofing examples in my
previous email. This is not only a security issue. It is an
interoperability issue too. We have a number of possibilities for
IDNA200X:

(1) make the mappings (dots, case, nfkc) part of the protocol
(2) make them a normative reference
(3) make them an informative reference
(4) don't reference them at all

If the mappings are not in the protocol, they can be in a number of
different places:

(a) a normative or informative RFC in the IDNA200X series
(b) a normative or informative RFC outside the IDNA200X series
(c) the IDNA2003 series (unchanged)
(d) a normative or informative part of IRIbis
(e) a normative or informative part of HTML5

The further down these lists (1) to (4) and (a) to (e) you go, the
more danger there is of less interoperability and less security.

Erik

On Dec 8, 2007 10:13 AM, John C Klensin <klensin at jck.com> wrote:
>
>
> --On Saturday, 08 December, 2007 09:04 -0800 Erik van der Poel
> <erikv at google.com> wrote:
>
> > John,
> >
> > There certainly is a danger, but I don't think it's limited to
> > the non-ASCII dots, nor would I draw the same conclusion.
> >
> > If we had the string mit.edu in an email, where the 'm' was
> > full-width and .edu was operated by an unscrupulous or
> > error-prone registry operator, cutting and pasting that string
> > into an IDNA-unaware browser would take the user to the wrong
> > MIT.
> >...
>
> Erik,
>
> I tend to agree with Gervase -- there is little point in going
> over the spoofing problems again unless someone has something
> new to say.
>
> But the dot problem is a very special case (it is no accident
> that the conversion/matching rule is a special case in 3490 and
> not, e.g., part of nameprep).  _All_ other pieces of the IDNA
> puzzle are transparent to competently-written software that is
> not IDNA-aware.      Either those systems "see" the A-labels
> (punycode) or they see some sequence of octets (for which RFC
> 2181 specifies and clarifies handling).  But variant periods
> require than software that is not IDNA-aware be IDNA-aware to
> parse the domain names into labels.
>
> To preserve them as something that can be passed between
> systems, we need to retrofit the entire structure that is based
> on the DNS.  That is not about spoofing, or registry behavior,
> or bad guys, although it opens up some possibilities for them.
> It is about the fundamentals of DNS interoperability and
> interoperability of IDNA with the DNS.
>
> I also note that those dots in IDNA2003 are the only reason why
> the protocol needs to deal with full domain names at all and not
> just with labels.   That added bit of complexity is probably
> something we should have spotted as a warning sign, but, for
> whatever reason, we didn't do so until now.
>
>     john
>
>