Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

["Eric A. Hall" <ehall@ehsco.com>]

Everything else discussed is irrelevant. We are there.

on 6/9/2002 9:16 PM Adam M. Costello said the following:

> "Eric A. Hall" <ehall@ehsco.com> wrote:

>>When the RR rules are defined, they will get stringprep profiles
>>assigned to them.  At that point, the applications which create and
>>interpret the unencoded labels are the only ones that need to know
>>anything, and the infrastructure can store, transfer, compare and
>>convert the opaque octets.
> 
> I'm finally starting to understand your vision.  In order to correctly
> convert labels between the non-ASCII form and the ACE form, or to
> compare two labels, you would need to EITHER know and perform the
> preparation algorithm for this particular label OR be guaranteed that
> the the appropriate preparation has already been applied (in which case
> you don't need to know what it is).

Exactly. Any node in the path can convert any RR (whose message structure
is understood) between IDNA and ACE simply be piping from one to the
other. They don't need to know the capitalization or normalization rules
which were used. It's just octets.

> That's interesting, but I see a security concern:  What if the entity
> handing you the label is maliciously not applying the appropriate
> preparation?  It can trick you into making errors when comparing labels,
> or trick you into converting a label into a non-equivalent label.  If
> you don't know the appropriate preparation algorithm, you can't detect
> this or protect yourself from it.

That's why DM-IDNS-00 required the app to perform validation. This is
discussed in the first paragraph of the Security Considerations section:

 |   Where possible, this specification strengthens DNS with multiple
 |   checks. For example, this specification requires that domain names
 |   be validated three times before they are used by applications:
 |   once on specification, once on entry at the authoritative zone or
 |   hosts database, and once again when the answer data is received by
 |   the requesting application.

> In your vision of the world (as I understand it), the ASCII
> infrastructure would use ACE, while the new improved infrastructure
> would use prepared-UTF-8, where the preparation is not the same for all
> labels.

Actually, I kind of expect that tighter rules will be picked up for the
STD13 RRs at the same time (with a formal definition of hostnames, etc).
Some of the stringprep profiles will be for localpart and SRV anyway so
those can be reused without effort. I'll leave that up to DNSEXT but I am
kind of expecting it to happen (if I can proceed with this model at all).
I am also expecting that they will want to use some of the other things as
generic updates to STD13. The query timer would be useful for things like
TCP fallback and DNSSEC as much as they are to IDNS.

> But I don't see what's so great about prepared-UTF-8 versus ACE.

Well, that's another argument for another day. The data has to be cleansed
before it can reasonably and safely be used by any process, so its not a
big deal to have the application do this. At that point, the question is
whether or not direct UTF-8 access offers the application and/or protocol
any benefits, which it does.

>>>If you only care about the end applications, which know the special
>>>semantics of the special labels, then just use a different prefix
>>>to go with your different Stringprep profile.  Then you can be sure
>>>that entities that know IDNA but don't know about your special
>>>labels won't accidentally muck with them.
>>
>>No, that won't work.
> 
> I don't see why not.  At some point, someone needs to perform Stringprep
> with some profile.  Why can't that entity go ahead and do the whole
> transformation at the same time (Unicode to ASCII, prepend the prefix)?
> What's the advantage of doing only the Stringprep part?

Because EDNS->ACE conversion by some cache in the middle will require that
the cache have knowledge of the appropriate prefix tag. Everytime you roll
out a new stringprep profile, you have to tell *everything* that *might*
do conversion what the prefix is. This requires pgrades to the resolvers,
the caches, the replication partners, everything. Nobody will do it.

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