Subject: Re: Native UCS support in DNS versus IDNA

From: Dan Oscarsson <[email-masked]>
Date: Thu, 24 Jan 2002 17:23:02 +0100

>> I think DNSSEC will have to enhanced with how to handle non-ASCII.
>
>Why? DNS can handle any string of bytes including DNSsec.

Yes, but to do case-insensitive matching on UCS you have to
expand the matching algorithm comared to today.

>Thus it seems just as simple to say that the zone contains
>	<ace-name>	IN	A 1.2.3.4
>	<utf-8-name>	IN	A 1.2.3.4
>	<ace-name>	IN	SIG ...
>	<utf-8-name>	IN	SIG ...
>It is true that the first record above can be generated on the fly, but
>it doesn't save much space when the records are signed.

The ACE-version of the name is not part of the zone. ACE is only for
backward compatibility. If I do a lookup in DNS, or a zone transfer,
with a UCS aware client, it will only get UCS encoded data back
if the server is UCS aware. Convertion to ACE is done if the client
cannot handle UCS. I would recommend that DNSSEC is not done
on ACE encoded data. The original format of the zone is native UCS
in the form of UTF-8, not ACE format. You do not want to
require a zone to contain two versions of every record with labels
containg non-ASCII? Nobody would like to enter two versions
of the same name and what would happen with the IDNA solution?
The IDNA solution does only contain records with ACE labels.

This may be an additional complication apart from my original
query if IDNA should be introduced due to the additional
overhead it will produce for a native solution.

   Dan

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 25 Jan 2002 13:32:36 +0100 (CET)

> The IDNA solution does only contain records with ACE labels.

Taking your claim that you don'tever  want dual records for the same 
underlying name it seems like there is two choices:
1. IDNA forever - SIG records for the ACE-name records etc
2. ACE-name record generated on the fly by server. No SIG records for
   ACE-names.

I agree with your argument that #1 is not the most efficient encoding of IDN
names, but I think that #2 either will not happen in practise or that it
will further delay DNSsec.
Not happen at all because: I assume folks want IDN support tomorrow
thus some zones want to do this without waiting for new DNS server software
(and we can't prevent them from doing so).
Thus they takes today's DNS server software and places ACE names in the zone.
If the also see a benefit in providing DNSsec they sign the zone.
Thus there would be some secure zones containing ACE names.
How can they be conviced that they should drop the DNSsec (no more SIGs for the
ACE names) for some better efficiency in the names over the wire?

Will further delay DNSsec deployment because:
For the zones that actually deploy the new 'ACE on the fly' DNS server
and then want to deploy DNSsec the clients will only be able to take advantage
of DNSsec if all the DNS servers on the path from the client to the 
authoritative servers support the new scheme used to distinguish UCS labels
from ASCII labels.

So while the final point of UCS support in all servers and no ACE
looks attractive, there are significant issues around getting from here to
there that makes it look a lot less attractive.

Of course, #2 also assumes that the security property is not per zone but
per name/RR in the zone. Others might have issues with such an approach...

  Erik