Subject: [Gen-art] Gen-ART review of draft-ietf-idnabis-defs-11.txt

From: Suresh Krishnan <[email-masked]>
Date: Fri, 16 Oct 2009 18:23:45 -0400

I am the assigned Gen-ART reviewer for
draft-ietf-idnabis-defs-11.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is almost ready for publication as Proposed
Standard but I have a few comments.

Minor
=====

* Section 2.3.1 Page 8

==> "XN-labels are further divided in those whose remaining
  characters (after the "xn--") are valid output of the Punycode
  algorithm."

... and what else?

==> U-labels are used before their definition

==> Since -- is already implied for R-LDH labels shouldn't this text

"Labels within the class of R-LDH labels that are not prefixed with 
"xn--" are also not valid IDNA-labels."

be replaced with

"Labels within the class of R-LDH labels that are not prefixed with 
"xn" are also not valid IDNA-labels."

* Section 2.3.2.4

"Equivalence between a U-label and an A-label determined by
  translating the U-label form into an A-label form and then testing
  for an exact match between the A-labels."

Given that the transformation in the other direction (A-label to U-label 
and then compare) is going to give the same result, is there a specific 
reason for picking this direction for the transformation? i.e. is 
Punycode encoding more efficient than decoding?

* 4.4 Security considerations

Should this section mention issues with visually similar domain names 
causing issues with non-matching certificates. If this happens the user 
is probably going to get very confused.

Thanks
Suresh

---

From: Vint Cerf <[email-masked]>
Date: Sat, 17 Oct 2009 12:31:26 -0400

Thanks Suresh, we will attend to these points.

v

On Oct 16, 2009, at 6:23 PM, Suresh Krishnan wrote:

> Given that the transformation in the other direction (A-label to U- 
> label and then compare) is going to give the same result, is there a  
> specific reason for picking this direction for the transformation?  
> i.e. is Punycode encoding more efficient than decoding?
>
>
> Should this section mention issues with visually similar domain  
> names causing issues with non-matching certificates. If this happens  
> the user is probably going to get very confused.
>
> Thanks
> Suresh
>
>
>
>
>
>
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2009 00:09:03 -0400

--On Friday, October 16, 2009 18:23 -0400 Suresh Krishnan
<[email-masked]> wrote:

>...
>   characters (after the "xn--") are valid output of the
> Punycode algorithm."
> 
> ... and what else?

Fixed, but not very well.  Given the xml2rfc difficulties in
making intra-document cross-references, to anything but a
section, I had to resort to a vague forward pointer.  But at
least the sentence no longer leaves one hanging.

> ==> U-labels are used before their definition

Well, not really because the reference I think you are referring
to is preceded by a forward pointer in bullet 5 of Section 1.3.
While it would be really good to have all of these definitions
sorted into strict order, the WG has tried that in rewrite after
rewrite.  The experience has been that it cannot be done, or
cannot be done in a way that doesn't reduce clarity.  What makes
this equally problematic is that the WG sorted out terminology
and got it consistent across the document set at great pain.
Because of the risk of causing unintentional side-effects, I
believe that we should avoid trying to re-tune terminology --or
terminology organization-- changes unless they are clearly
required to make things clear.  In this area, "requires some
skipping forward in the document" is not, IMO, sufficient
justification for incurring those risks.  Of course, if the WG
or IESG disagree, I'll try to do it.

> "Labels within the class of R-LDH labels that are not prefixed
> with "xn--" are also not valid IDNA-labels."
> 
> be replaced with
> 
> "Labels within the class of R-LDH labels that are not prefixed
> with "xn" are also not valid IDNA-labels."

Maybe, but the terminology used throughout the IDNA materials
(both this set of documents and the 2003 ones) has been that the
"prefix" is "xn--".  That statement in the document is still
true, so, while your correction might be an improvement in
isolation, I think is might create more confusion than it
eliminates (see the comments above about trying to re-tune
terminology). 

> Given that the transformation in the other direction (A-label
> to U-label and then compare) is going to give the same result,
> is there a specific reason for picking this direction for the
> transformation? i.e. is Punycode encoding more efficient than
> decoding?

There are two reasons.  One is that IDNA2003 supported a great
many mapping arrangements, so that (using IDNA2008 terminology)
converting from a Unicode string to an A-label and then to a
U-label might not yield the original string.  Doing things in
the order specified provides some backward compatibility
protections.  The other is that the WG was considering requiring
some small set of mappings until extremely late in the process.
Converting to A-labels and then comparing would be stable
regardless of the outcome of those discussions; converting to
U-labels might not be.

> Should this section mention issues with visually similar
> domain names causing issues with non-matching certificates. If
> this happens the user is probably going to get very confused.

The confusable character issue is covered in the Protocol
document (with cross-references there improved in the
post-last-call version).  The specific flavor of that issue with
certificates seemed to be out of scope, however, as a general
observation, as long as everyone is careful to keep strings in
canonical form (a different problem from visual confusability)
the certificate problem with IDNs is really no different from
possible mismatches between ASCII strings like "abcld" and
"abc1d": if you are looking closely and have fonts that lend
themselves to discrimination, then there will be no problem.  If
not...   IDNs change the magnitude of the problem by shifting it
from perhaps three or four sets of confusable characters (note,
for example, that "rn" in some fonts, and especially if the
typesize is small, may not be easily distinguished from "m") to
thousands.  But the difference is one of scale, not kind.

thanks,
       john

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 28 Oct 2009 15:53:24 -0400

Hi John,
   Thanks for your detailed response. Your explanations and suggested 
changes resolve all the issues I raised.

Cheers
Suresh