Re: [idn] SC/TC equivalence

[David Hopwood <david.hopwood@zetnet.co.uk>]

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

Erik Nordmark wrote:
> Adam M. Costello <amc@cs.berkeley.edu> wrote:
> > Thank you!  One thing that should be considered by anyone contemplating
> > server-side equivalence rules is that clients will not know that the
> > names are equivalent.  For web browsers, this will affect visited link
> > coloring, page caching, cookie permissions, etc.  Similar pitfalls will
> > exist in other applications.  Zone administrators willing to tolerate
> > such limitations are free to do server-side equivalence matching to
> > their heart's content.  It would be ludicrous for this working group to
> > try to prohibit this practice, because it's equivalent to populating the
> > zone with identical data for all the matching names, which is obviously
> > permitted.
> 
> I don't think this WG prohibits this - it shouldn't as far as I can tell.
> But the ability of the client to tell that it got the right answer to a
> DNS query does add some severe constraints.
> [I assume DNS protocol experts will correct me if I got this wrong.]
> 
> If the client asks for A and gets a response with QNAME A' and answer X
> then ...

It won't - it will get a response with QNAME A.

For DNSSEC, all responses for names that are actually used will have to be
signed. This is an inevitable consequence of wanting TC/SC equivalence without
putting TC/SC folding in nameprep (that is, the client-side canonicalization
function). The decision that WG has to make is whether TC/SC folding is in
nameprep or not. If that answer is "yes", it also has to define the folding,
and require that all clients implement it.

Personally I don't think nameprep should include any folding that depends
on the semantics of particular languages - even if that causes inefficiencies
for DNSSEC. The 'ONE' work demonstrates how complicated "semantic folding"
can be:

James Seng wrote:
# Our (as in i-DNS.net) approach have been working on Onomastic
# Normalization Engine for registration time to handle possible multiple
# names since Nov last year. The work on ONE turns out to be much more
# complex and time consuming then originally expected. And there is
# different ONE for each language (See ONE-J and ONE-K at
# http://playground.i-dns.net/one/index.html).

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBO3PhLjkCAxeYt5gVAQHFQwgAn1B631hvNs0zJSNGA04BCU4tNsxwWE9O
3PKmKt49Rm9zpGh5Sq3HEHr1bmsQQoZshXzk1w+jmg9U3d4Fsst4ry03PT7ScjFX
wPBJ6gyZ/A/R2KdZ770F9kLjg9jqSTnFtQIc2nsHGYXP1MmdWlPHH5qWDSoqhURU
IFBhWcOGSY1J+6c8+CqopG63RVLrISoB4oDMxCboQPcwt30e5RVLbHR6V+bM0gY6
GdqmSIv3w7xXEMoMKed8d9vIkKG3aGsYwAzHI/8jde7AuwS+LBWgPbOt0LzRZPau
UzATGhdcI+hDxe0AVO2ynz7vHt8MKZd7AxSGLnqBCXWhiqlpxLmLaw==
=FNbG
-----END PGP SIGNATURE-----