[idn] IDN/DNSSEC interaction

[Ted Hardie <Ted.Hardie@nominum.com>]

Hi,
	The security section of draft-ietf-idn-idna-04.txt describes a
potential authentication problem which would arise if a user could
enter a single internationalized name and be connected to different
servers based on different interpretations of the internationalized
host name.  The primary implication of this is obviously that there
must be no ambiguity in any of the transforms specified by IDNA.  
	I believe, however, that there are some other authentication
issues and that it would be valuable to add a subsection under
6. ("Implications for typical applications using DNS") that describes
the implications of IDNA for DNSSEC and vice versa.  I've drafted some
proposed text below, which I hope folks will tear apart, re-build, and
make better.  I would suggest placing it between the current 6.3 and
6.4.  
	The basic messages are: ToASCII must occur before signing a
zone; DNSSEC checks confirm the authenticity of signed resources, not
the original hostnames or the correctness of the mapping between
between the hostname and the record; if special purpose proxies or
forwarders are used to transform user input to IDNA hostnames, then
those proxies must be earlier in the resolution flow than DNSSEC
authenticating nameservers for DNSSEC to work.  None of this stuff
seems controversial, but I do think it needs to be called out more
directly.
			regards,
				Ted Hardie


6.x  DNSSEC authentication of IDNA hostnames

DNS Security [DNSSEC] is a method for supplying cryptographic
verification information along with DNS messages. Public Key
Cryptography is used in conjunction with digital signatures to provide
a means for a requester of domain information to authenticate the
source of the data.  This ensures that it can be traced back to a
trusted source, either directly, or via a chain of trust linking the
source of the information to the top of the DNS hierarchy.

IDNA specifies that all internationalized host names stored in DNS
servers must be valid names processed with the ToASCII operation.
This processing must be complete prior to a zone being signed by the
private key for that zone.  Because of this ordering, it is important
to recognize that DNSSEC authenticates the ACE-encoded resource, not
the internationalized hostname or the mapping between that hostname
and its ACE-encoding form.  The canonical name, in other words, is the
output of ToASCII.  In the presence of DNSSEC, this is the name that
MUST be signed in the zone and MUST be validated against.  It also
SHOULD be used for other name comparisons, such as when a browser
wants to indicate that a URL has been previously visited.

One consequence of this for sites deploying IDNA in the presence of
DNSSEC is that any special purpose proxies or forwarders used to
transform user input into IDNA hostnames must be earlier in the
resolution flow than DNSSEC authenticating nameservers for DNSSEC to
work.