Protocol - security issues and others

[Mark Davis]

Protocol*Other than A-Label and U-Label issue already covered:*

**

[[anchor2:
This paragraph is not normative and not required to understand this
spec. It will be removed in version -07 unless someone provides a
convincing rationale for retaining it.]]


I strongly agree on removal.

------------------------------

2.
Comparison of labels SHOULD be done on the A-label form, using an
ASCII case-insensitive comparison as with all comparisons of DNS
labels. Because A-labels and U-labels can be transformed into each
other without loss of information, comparison of native character
labels is possible if the application first carefully verifies that
the strings are U-labels.

=>

2. Comparison of labels MUST be done on equivalent forms: either both
A-Label forms or both U-Label
forms. Because A-labels and U-labels can be transformed into each
other without loss of information,
these comparisons are equivalent. However, when the A-label form is
compared, it MUST use
an ASCII case-insensitive comparison as with all comparisons of DNS labels.
Comparison is only valid if the putative labels have been verified to be
either A-Labels or U-Labels.


*Rationale.* Since either form of comparison is precisely equivalent, the
SHOULD is misplaced. The text should focus on what is required, and alert
the user that both the A-Label and the U-Label need verification.

------------------------------

The
registry MAY permit submission of labels in A-label form. If it does
so, it SHOULD perform a conversion to a U-label, perform the steps and
tests described below,...

=>

The
registry MAY permit submission of labels in A-label form. If it does so, it
MUST
perform a conversion to a U-label, perform the steps and tests
described below,...


*Rationale.* It is pointless to have a massive and complex process in
IDNA2008 to describe what a registry must do to verify U-Labels if it is
trivial to circumvent the entire process and supply invalid A-Labels!! This
is especially because the Lookup process is more lenient than the
registration process. We need to close this truck-sized hole.

------------------------------

*Also: *In the definitions, we should make clear what "A-Label form" and
"U-Label form" mean. According to what I read of the text, they are
something like "strings that appear to be A-Labels (resp U-Labels), but have
not been verified to be so". I called that "putative A-Label" or "putative
U-Label" in my message on these definitions, because that term is used in
some places. But we need to have a single term, use it consistently, and
provide a definition so that the meaning is precise.

I would also suggest having the terms "invalid A-Label" = putative A-Label
that is not an A-Label, and the same for "invalid U-Label".

------------------------------

As
a local implementation choice, the implementation MAY choose to map
some forbidden characters to permitted characters (for instance
mapping uppercase characters to lowercase ones), displaying the result
to the user, and allowing processing to continue. However, it is
strongly recommended that, to avoid any possible ambiguity, entities
responsible for zone files ("registries") accept registrations only
for A-labels (to be converted to U-labels by the registry as discussed
above) or U-labels actually produced from A-labels, not forms expected
to be converted by some other process.

=>

As a local implementation choice, the implementation MAY
choose to map some forbidden characters to permitted characters (for
instance mapping uppercase characters to lowercase ones), displaying
the result to the user, and allowing processing to continue. However,
if this is done, the mapping SHOULD be in accord with the general rules for
IDNA2003 mappings (NFKC mapping plus case folding), and the implementation
SHOULD request the user to confirm that the resulting U-Label is in fact the
requested string.


*Rationale. *The text left a hole open for some of the very unpleasantness
that removing the mapping was supposed to prevent: people thinking that they
were registering one string when they were in fact registering a different
one.

------------------------------

4.3.2.1. Rejection of Confusing or Hostile Sequences in U-labels

=>

4.3.2.1. Rejection of Hyphen Sequences in U-labels


*Rationale. *At this point in the text, the application of 4.3.2.1 is to --
in 3rd and 4th position. That is neither Confusing nor Hostile -- it is
restricted because we want to allow for future signatures. (And what the
heck is a Hostile Sequence: ":-("?)

------------------------------

[[anchor14:
Should this paragraph be removed? Note that I've been strongly
encouraged to supply specific examples to reduce abstraction and
questions about the appropriateness of the text. -JcK]]


Yes, unless you want to add specific examples, it needs to be removed. And
even if you do add examples, it would need to be moved to Rationale.

------------------------------

Strings
that have been produced by the steps above, and whose contents pass
the above tests, are U-labels.

=>

Move to after 4.5.


*Rationale. *Otherwise this is false, since an A-Label generated from a
string that passed the "above" tests could be too long.

------------------------------

The
failure conditions identified in the Punycode encoding procedure
cannot occur if the input is a U-label as determined by the steps
above.

=>

[REMOVE]


*Rationale.* It is false. The A-Label could be too long.

------------------------------

The
Unicode string MAY then be processed to prevent confounding of user
expectations. For instance, it might be reasonable, at this step, to
convert all upper case characters to lower case, if this makes sense
in the user's environment, but even this should be approached with
caution due to some edge cases: in the long term, it is probably
better for users to understand IDNs strictly in lower- case, U-label,
form. More generally, preprocessing may be useful to smooth the
transition from IDNA2003, especially for direct user input, but with
similar cautions. In general, IDNs appearing in files and those
transmitted across the network as part of protocols are expected to be
in either ASCII form (including A-labels) or to contain U-labels,
rather than being in forms requiring mapping or other conversions.
Other examples of processing for localization might be applied,
especially to direct user input, at this point. They include
interpreting various characters as separating domain name components
from each other (label separators) because they either look like
periods or are used to separate sentences, mapping halfwidth or
fullwidth East Asian characters to the common form permitted in
labels, or giving special treatment to characters whose presentation
forms are dependent only on placement in the label. Such localization
changes are also outside the scope of this specification.
Recommendations for preprocessing for global contexts (i.e., when
local considerations do not apply or cannot be used) and for maximum
interoperability with labels that might have been specified under
liberal readings of IDNA2003 are given in [IDNA2008-Rationale]. It is
important to note that the intent of these specifications is that
labels in application protocols, files, or links are intended to be in
U-label or A-label form. Preprocessing MUST NOT map a character that
is valid in a label as specified elsewhere in this document or in
[IDNA2008-Tables] into another character. Excessively liberal use of
preprocessing, especially to strings stored in files, poses a threat
to consistent and predictable behavior for the user even if not to
actual interoperability. Because these transformations are local, it
is important that domain names that might be passed between systems
(e.g., in IRIs) be U-labels or A-labels and not forms that might be
accepted locally as a consequence of this step. This step is not
standardized as part of IDNA, and is not further specified here.


=>

The Unicode string MAY then be processed to for interoperability and
backwards compatibility with IDNA2003. Such preprocessing MUST be in
accordance with the mappings used in IDNA2003: that is, normalization with
NFKC and case-folding.

*Rationale.* Otherwise, by allowing any and all mappings, we would be
opening the door to massive security issues.

------------------------------

o
Labels containing other code points that are shown in the permitted
character table as requiring a contextual rule ("CONTEXTO" in the
tables), but for which no such rule appears in the table of rules.
With the exception in the rule immediately above, applications
resolving DNS names or carrying out equivalent operations are not
required to test contextual rules, only to verify that a rule exists.

=>

[Delete]


*Rationale.* It is pretty pointless to require checking that rules exist if
we aren't going to require that people actually verify that the rules apply.

------------------------------

an
attempt to look up and resolve such strings will almost certainly lead
to a DNS lookup failure except when wildcards are present in the
zone.

=>
[clarify. Why are we saying "almost certainly"? What are the other failure
cases besides wildcards?]

------------------------------

IDNA
specifies that all internationalized domain names served by DNS
servers that cannot be represented directly in ASCII must use the
A-label form. Conversion to A-labels must be performed prior to a zone
being signed by the private key for that zone.

=>
[both "must"s to "MUST"?]

------------------------------

8.
Make bidirectional domain names (delimited strings of labels, not just
labels standing on their own) display in a non- surprising fashion
whether they appear in obvious domain name contexts or as part of
running text in paragraphs.

=>

8.
Make bidirectional domain names (delimited strings of labels, not just
labels standing on their own) display in a
less
surprising fashion whether they appear in obvious domain name contexts
or as part of running text in paragraphs.


Rationale. Because we couldn't get in the inter-label bidi checks, it is
only "less" surprising, not "non-" surprising.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081119/a51e6a57/attachment-0001.htm