Subject: [dns-dir] review of draft-liman-tld-names-05.txt

From: Peter Koch <[email-masked]>
Date: Mon, 1 Aug 2011 14:53:01 +0200

All,

this is a review of draft-liman-tld-names-05.txt for the DNS Directorate.
To my knowledge this document has not been last called yet, but is considered
as an AD sponsored Individual Submission.   An earlier version of this draft has
been discussed in the DNS Operations working group.  Since it aims at updating
a Standrads Track RFC, it was not considered for adoption in this particular WG.
However, independent of this formal obstacle, it did not gain traction.

>                   Top Level Domain Name Specification
>                         draft-liman-tld-names-05

> Abstract

>    The syntax for allowed Top-Level Domain (TLD) labels in the Domain
>    Name System (DNS) is not clearly applicable to the encoding of
>    Internationalised Domain Names (IDNs) as TLDs.

>    This document provides a concise specification of TLD label syntax
>    based on existing syntax documentation, extended minimally to
>    accommodate IDNs.

>    This document updates RFC1123.

Summary: To the extent that RFC 1123 actually or allegedly is in conflict with
today's content of the DNS root zone (or vice versa), an IETF action might be
advised. However, this draft goes far beyond what would be necessary to resolve
the potential ambiguity posed by RFC 1123 and in fact mixes protocol and registration
policy in a way that does not seem appropriate to me in today's environment which is
more complicated than when RFC 1123 was published.  My recommendation is to remove
all attempts from the draft that phrase what "correct", "inambiguous" or
"alphabetic" IDN TLDs or IDN labels are and strictly update only the one
paragraph in RFC1123 that suggests "xn--" may ot appear in a TLD label.

If there is enough support, the IETF could attempt to give recommedations regarding
the IDN TLD registration policy, but this has to happen in a different document that
will not be on standards track.  Eventually the responsibility for the TLD
name registration policy remains with the IANA function at ICANN that is not
governed by the IETF and in particular is out of the scope of RFC 2860.

> 1.  Introduction

>    The syntax of TLD labels ("TLD DNS-Labels", as defined in Section 2)
>    is specified in [RFC1123], where such labels are asserted to be
>    "alphabetic" within a section of that document entitled "DISCUSSION".
>    This can be interpreted as requiring that the hyphen character ("-")
>    and numeric digits be excluded from TLD DNS-Labels.  Such a
>    restriction would not accommodate the US-ASCII encoding of
>    Internationalised Domain Names (IDNs), as specified in [RFC5890].  A
>    more detailed discussion of the existing specifications can be found
>    in Section 3.

>    This document extends the syntax of allowable TLD DNS-Labels to
>    support IDNs, but places some restrictions on the choice of IDN
>    labels.  These restrictions are intended to be consistent with the
>    existing specification for US-ASCII TLD DNS-Labels.  See Section 4
>    for the updated specification.

>    This document focuses narrowly on the issue of allowable DNS-Labels
>    in TLDs and does not (and is not intended to) make any other changes
>    or clarifications to existing domain name syntax rules.

>    It is carefully noted that the specification in this document is not
>    the only factor in choosing suitable TLD DNS-Labels, and that many
>    considerations external to the IETF are included in that wider
>    policy.  See Section 5 for more discussion of policy considerations.

> 2.  Definitions

>    The term DNS-Label is used in this document to have precisely the
>    same meaning as the term "label", as introduced in [RFC1034], section
>    3.1.  A DNS-Label denotes one node in a DNS tree.  A DNS-Label is
>    zero to 63 octets in length.  The term "DNS-Label" refers exclusively
>    to the "wire format" of the label, and not to any presentation format
>    of the label.

>    A Top-Level Domain (TLD) DNS-Label is the right-most ("highest-
>    level") DNS-Label in a fully-qualified domain name.

>    The terms A-Label and U-Label are used in this document as defined in
>    [RFC5890].

> 3.  Background

>    [RFC0952] defines a host name as follows:

>       'A "name" ... is a text string up to 24 characters drawn from the
>       alphabet (A-Z), digits (0-9), minus sign (-), and period (.).
>       Note that periods are only allowed when they serve to delimit
>       components of "domain style names".  (See RFC-921, "Domain Name
>       System Implementation Schedule", for background).  No blank or
>       space characters are permitted as part of a name.  No distinction
>       is made between upper and lower case.  The first character must be
>       an alpha character.  The last character must not be a minus sign
>       or period.'  [Unnumbered section titled "ASSUMPTIONS", first
>       paragraph]

>    [RFC1123] reaffirms this definition, but makes one change to the
>    syntax:

>       'The syntax of a legal Internet host name was specified in RFC-952
>       [DNS:4].  One aspect of host name syntax is hereby changed: the
>       restriction on the first character is relaxed to allow either a
>       letter or a digit.  Host software MUST support this more liberal
>       syntax.'  [Section 2.1]

>    In addition, the DISCUSSION section of Section 2.1 says:

>       'However, a valid host name can never have the dotted-decimal form
>       #.#.#.#, since at least the highest-level component label will be
>       alphabetic.'  [Section 2.1]

>    Some implementers may have understood the above phrase 'will be
>    alphabetic' to be a protocol restriction.

This _may_ be true, but since this restriction is only applicable in the
context of the complete paragraph which the draft fails to quote:

           If a dotted-decimal number can be entered without such
           identifying delimiters, then a full syntactic check must be
           made, because a segment of a host domain name is now allowed
           to begin with a digit and could legally be entirely numeric
           (see Section 6.1.2.4).  However, a valid host name can never
           have the dotted-decimal form #.#.#.#, since at least the
           highest-level component label will be alphabetic.

These considerations apply to confusing an FQDN with a dotted quad and
just deduce from the shape of then current TLDs that a full ambiguity
"never" can happen. No harm is done unless and until we'd see an all-digits
TLD.  In today's environment it might be a good idea to spend some cycles
on IPv6 literals, too.

>    Neither [RFC0952] nor [RFC1123] explicitly states the reasons for
>    these restrictions.  It might be supposed that human factors were a
>    consideration; [RFC1123] appears to suggest that one of the reasons
>    was to prevent confusion between dotted-decimal IPv4 addresses and
>    host domain names.  In any case, it is reasonable to believe that the
>    restrictions have been assumed in some deployed software, and that
>    changes to the rules should be undertaken with caution.

This is hand waving, IMHO.

>    In order to accommodate the wish to express TLD names in scripts
>    other than Latin (or rather, the US-ASCII subset of Latin), it is
>    necessary to allow non-alphabetic characters in the corresponding TLD
>    DNS-Labels.  To minimize changes, the U-label form of a TLD name is
>    restricted in ways functionally compatible with the restrictions
>    (from [RFC0952] and [RFC1123]) on US-ASCII TLD names, by applying
>    rules analogous to those already imposed on US-ASCII TLD DNS-Labels
>    to TLD U-labels.

>    However, deployed software that checks DNS top-level labels for
>    conformance with an alphabetic restriction will not recognize such
>    corresponding A-Labels (i.e., U-labels represented in their US-ASCII
>    form).

So, since A-labels will always start with "xn--" and are likely to contain
digits and another "-", "deployed software" that makes (misguided) assumptions
about the characters used in TLD labels is not helped.

> 4.  TLD Label Syntax Specification

>    This document relaxes the existing specification to allow TLD DNS-
>    Labels to be well-formed A-Labels, but places restrictions on their
>    corresponding U-Labels.  That is, not every well-formed A-Label is a
>    valid TLD DNS-Label.

Nit: as per the definition above "DNS-Label" refers to the wire format whereas
"A-label" as per RFC 5890 are in presentation format, thus they cannot be
equal but only represeantations of each other.

>    The ABNF expression that matches a valid TLD DNS-Label is as follows:

>              tld-dns-label = traditional-tld-label / idn-label

>              traditional-tld-label = 1*63(ALPHA)

>              idn-label = Restricted-A-Label

>              ALPHA    = %x41-5A / %x61-7A   ; A-Z / a-z

>    A Restricted-A-Label is a DNS-Label which satisfies all the following
>    conditions:

>    1.  the DNS-Label is a valid A-Label according to [RFC5890];

>    2.  the derived property value of all code points, as defined by
>        [RFC5890], is PVALID;

>    3.  the general category of all code points, is one of { Ll, Lo, Lm,
>        Mn }.

>    This new specification reflects current practice in registration of
>    TLD names by the IANA, extended to accommodate IDNs.

There is no justification or explanation given for this restriction and also no
way in which this change to the U-label would help deployed software that allegedly
checks TLD labels for being "alphabetic".

> 5.  Policy Considerations

>    This document provides a technical specification that limits the set
>    of TLD DNS-Labels that are available for assignment; it does not aim
>    to encapsulate the full policy framework within which TLD names are
>    chosen.

>    At the time of writing, the policy under which TLD names are chosen
>    is developed and maintained by ICANN in consultation with a wide base
>    of stakeholders.  As the Internet continues to grow to serve new user
>    communities, applications and services, it is to be expected that the
>    corresponding policy will be changed accordingly.

It is unclear whether this draft attempts to reflect current IANA/ICANN root zone
TLD naming policy into an IETF standard and why that would be advised, justified
or desirable - or vice versa in which case the documents lacks a justification
for the restriction of TLD labels.

> 6.  IANA Considerations

>    While this document makes no requests of the IANA, management of the
>    root zone is an IANA function.  This document expands the set of
>    strings permitted for delegation from the root zone, and hence
>    establishes new limits for the corresponding IANA policy.

Management of the root zone is an IANA function outside the scope of RFC 2860,
whereas "IANA considerations" guide IANA under exact that MoU.  Therefore, this
text has no effect.  The last sentence, though, answers my question raised after
the previous paragraph: again, the technical justification for limiting the
TLD code points in the context of the RFC 1123 ambiguity is missing.

> 7.  Security Considerations

>    This document is believed to have limited security implications.

>    General discussion about the security effects of internationalized
>    labels can be found in [RFC5890], section 4.  Those considerations
>    apply equally to TLD labels.

>    The creation of new TLDs has the potential to conflict with software
>    which (for example) predates and correspondingly does not accommodate
>    new TLD names.  Such software problems might in turn lead to security
>    vulnerabilities, e.g. in the case where a DNS name specified by a
>    user is truncated or otherwise misinterpreted, causing an application
>    to interact with a different remote host from that which the user
>    intended.  It should be noted that this is not a new phenomenon, and
>    has been observed following the creation of new (US-ASCII) TLD names
>    prior to the publication of this document.

>    The issue that some Unicode characters can be confused with each
>    other is discussed at length in the Security Considerations section
>    of [RFC5890].

With the remarks made above, this is mostly irrelevant to the issue at hand.
What might be discussed here is the confusion of IP address literals
(v4 and v6, for that matter) with FQDNs and how the (clarified) section
of RFC1123 relates to this problem.

I do not feel right comfortable to "send text" for changes since basically
i believe the draft would need a completely different approach that
explains the non-normative nature of the "can never happen" remark.
If anyone shares this view i'd be happy to come up with a counter proposal.

-Peter

---

From: Joe Abley <[email-masked]>
Date: Mon, 1 Aug 2011 08:09:33 -0700

Hi Peter,

Thanks for the thorough review.

I think we need some guidance at a higher-level for how (or if) to proceed with this work. I've sent a separate message to the DNS Directorate which presumably someone will get around to approving from the non-members-post mailman queue at some point.

Until we identify the preferred direction here, I'll defer responding to the points you raised below.

Joe