Subject: [idn] conflicts with ACE and STD13

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 09 Nov 2001 06:30:07 -0600

Three potential conflicts with ACE and STD13 labels:

1) Easy one first. There is a potential security problem with ACE
encodings of legacy LDH domains, in that it may be possible for a user to
manually encode an LDH label and provide false glue by providing
"bq--ehsco.com." which gets decoded as "ehsco.com.", particularly if a
delegating entity doesn't prevent it. idna-02 says this is illegal for
zones in particular, but it needs to happen anywhere that ACE is processed
as rich data rather than LDH. We should just declare any ACE encoded LDH
label as illegal to be rejected with extreme prejudice by any entity which
encodes OR decodes ACE. I'm putting this in the next UDNS spec, btw.

2) ACE precludes certain characters from being stored, and delegates some
of this process to idna's incoming filters. However, idna is only
concerned with host names, and some of the excluded values can be provided
as binary domain names (hyphen at the beginning and end of a binary domain
name is legal, for example). Will such strings blow up ACE? If so, these
labels need to be excluded from ACE conversion the same way that LDH
labels are. Can we get an enumeration on these?

3) Similar problem exists with domain names that contain eight-bit
characters outside LDH. This is a complex problem, so read all the way
through before you start composing a response. :)

Eight-bit character codes like 0xC3 are valid for use in internationalized
domain names (stored as the canonical UCS character representation) AND in
binary domain names (not for host identifiers, but for other uses such as
identifying a TXT RR).

Let us also assume that we have an IDNA compliant DNS server which is
aware of the various STD13 rules, and that it also generates ACE encoded
data based on the canonical UCS character values. As was mentioned in
problem (1) above, if a provided domain name consists of only alphabetic
characters from US-ASCII, then the server knows that an ACE encoded
equivalent of that name would be illegal, so it only generates the STD13
octet encoded output. In this case, a single input of code point value is
sufficient to determine the appropriate output format. Likewise, any UCS
characters entered with a value greater than U+0FF can only be represented
as ACE, so that's the only output format it has to worry about.

However, whenever a UCS character in the range of U+0000 through U+00FF is
provided, the software has to generate two output formats: one for the
STD13 octet encoding required for binary domain names, and another to
provide the ACE encoded representation of the canonical UCS character.

Now we have two encodings of the same UCS character: one is the STD13
octet encoding, and the other is the ACE encoding, and both forms need to
be maintained. This is actually not much of a problem by itself, because
the server software can choose which format to return based on the
encoding that was used by any matching query. EG, if the query was for
m[c3].domain.dom. and was provided with an ACE prefix, then the requester
wants the ACE form. Meanwhile, queries for m[c3].domain.dom. which do not
use an ACE prefix obviously want the binary octet form. When the query
explicity identifies the ENCODING it wants, the server has enough data to
make an intelligent decision.

However, there IS a conflict if the server doesn't have the second piece
of information. For example, let's create another domain name, which we'll
call alias.domain.dom. which is a CNAME for the UCS canonical
representation of "m[c3].domain.dom.", and which is stored in the
UCS-enabled server's UCS-enabled zone. But which output encoding does it
map to? When a query comes in for alias.domain.dom., does the user want
the m[c3] octet encoded TXT RR or do they want the international m[c3] RR
specified by the UCS character? Because the cname entry doesn't provide
any hints, the server can't tell which sequence to return.

This problem MUST be resolved, as it represents a fundamental conflict
between ACE and the binary label syntax whenever queries are processed
using their canonical UCS character code, and where multiple output
encodings are possible or required. At the least we need to say that if
there is a conflict, rename one of the labels. Even then, automatic
generation in only one format will result in wrong data for one of them.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 9 Nov 2001 09:18:11 -0800

>encodes OR decodes ACE. I'm putting this in the next UDNS spec, btw.

Your timing is amazing. Your message was posted about twenty minutes 
after the announcement of the new IDNA draft. That draft solves this 
problem (which was indeed a real problem in the idna-03 document).

>name is legal, for example).

The distinction between host names and domain names is subtle and 
hotly contested in the DNS world. The IDN WG is only dealing with 
host names, for now. This demarcation between these two has not been 
very important before now, but IDN is making it important.

>  Will such strings blow up ACE?

No. But that is not what is important here. What is important is the 
question of what are host names (and therefore must conform to IDNA) 
and what are not (and therefore are just unstructured octet strings).

>through before you start composing a response. :)

Did so. Agree that similar problems exist in all host/domain names 
that are not LDH. The problem here is identical to the problem 2

>encodings are possible or required.

The difference between host labels which are covered by IDNA and 
domain labels which are not must be well-defined before IDNA is 
finished. The -04 draft takes a step towards that, but it is not 
complete. Suggestions for specific wording for the draft on this 
topic are *greatly* appreciated.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 09 Nov 2001 15:43:51 -0600

> topic are *greatly* appreciated.

All domain names are unstructured eight-bit sequences, host names are a
specific subset of that range. Host names are the exception, domain names
are the rule. Treating domain names as the exception results in the above
problem. This isn't a simple block of text...

The draft I'm working on punts with the problem cases cited: labels which
only contain characters in the range 0x00 through 0x7E must only be
encoded as STD13 octet sequences and UTF-8, while domain names that have
any eight-bit value in the label are to be encoded as STD13 octet, ACE and
UTF-8 equally. If a server is unable to choose between STD13 and ACE
output encoding, it favors ACE on the assumption that it is more likely to
be Latin-1 than an eight-bit code, and that ACE has future processing
characteristics (can be used as CNAME for a host) whereas STD13 octet
encoding does not. This is definitely a punt which is guaranteed to fail
in more than one scenario. Some sort of group decision needs to be made on
this at some point; ambiguous matches in DNS are not cool.

Note that UTF-8 does not suffer this ambiguity, since it doesn't overload
a shared label: if the query arrived as UTF-8, the canonical UCS character
is encoded as UTF-8 and returned for the recipient to decode, so there is
no ambiguity as to which encoding should be used. Nor does it matter if
the client wanted STD13 binary domain or an internationalized domain name,
because there is no difference with this particular encoding scenario;
they asked for a code point in a specific encoding and we comply.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 09 Nov 2001 14:10:45 -0800

I appreciate you try to help with this problem, but it is not the DNS
protocol itself we talk about, but what is actually used as a protocol
element in the applications. We need text that explain when and why we have
any kind of (if any) restriction of what codepoints to be used here and
there. Have a look at the restriction list(s) in the nameprep document,
should that apply to domain names or only the subset host names?

I.e. I see this problem being orthogonal to the encoding of the Unicode
codepoints, and have not much to do with the DNS protocol, which already
can handle 0x00-0xFF.

    paf

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 09 Nov 2001 16:20:59 -0600

Patrik Fältström wrote:

> I.e. I see this problem being orthogonal to the encoding of the
> Unicode codepoints, and have not much to do with the DNS protocol,
> which already can handle 0x00-0xFF.

The root problem case is that the STD13 legacy label type is used to
provide multiple encodings; this is an overloaded data-type problem more
than anything else [OT: it is the same root problem case that required
EDNS extended labels to be used for UTF-8].

The readily-visible problem case is that the canonical UCS character code
will have two values when encoded, and the appropriate encoding cannot
always be determined (see above).

---

From: David Hopwood <[email-masked]>
Date: Sat, 10 Nov 2001 03:04:39 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> encodes OR decodes ACE. I'm putting this in the next UDNS spec, btw.

This is also in the spec for my proposal. (Bear with me; it is very nearly
ready.)

> of this process to idna's incoming filters.

ACE doesn't preclude any characters from being stored (if by ACE you mean
the encoding and decoding functions on labels). AFAICS neither does idna-04,
unless the name is explicitly required to be a hostname.

> However, idna is only

All ASCII-only labels, i.e. *(U+0000..007F).

> characters outside LDH.

There is no such thing as an "eight-bit character". Domain names (in the
sense you mean here) are octet strings, not character strings. U+00xx is not
the same as the octet with hex value xx. The latter is allowed in a domain
name according to the current specs, but it has no defined interpretation
as a character.

An IDN proposal is therefore free to define any mapping it likes between
an octet string domain name, and the corresponding character string, as
long as it preserves the current mapping (i.e. US-ASCII) as a subset.
Actually, it may even change the current mapping, as long as this change
only affects names that are known not to be used in practice (for example,
names that start with an ACE prefix).

> provide the ACE encoded representation of the canonical UCS character.

You're assuming that the current domain name <-> character string mapping
is defined by ISO-Latin-1. No such assumption is warranted: not all
octet string domain names will correspond to a Unicode string (just as not
all octet string domain names correspond to an ASCII string now).

The current requirements draft has a similar confusion between code points
and octets, as I pointed out in my suggested changes to it:

=====
draft-ietf-idn-requirements-08.txt:
# [3] The DNS protocol (the packet formats that go on the wire) MUST
# NOT limit the codepoints that can be used. A service defined on top of
# the DNS, for instance the IDN-to-address function, MAY limit the
# codepoints that can be used. The service descriptions MUST describe
# what limitations are imposed.

The packet formats that go on the wire use octet strings, not strings
of codepoints. In order to maintain compatibility with the requirements
of RFC 2181, it is the set of octet strings that must not be limited.

Also, there may be other restrictions on host names besides the set of
allowed codepoints (for example relating to mixing of left-to-right and
right-to-left scripts, or names that start with an ACE prefix).

=> [3] The DNS protocol (the packet formats that go on the wire) MUST
=> NOT limit, apart from in length, the set of octet strings that can be
=> used as an encoded domain name. A service defined on top of the DNS,
=> for instance the IDN-to-address function, MUST define a mapping between
=> host name strings and these octet string encodings, and MAY impose
=> limitations on host names, for example by restricting the set of
=> allowed codepoints. The service descriptions MUST describe what
=> limitations are imposed.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip