[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Specifying leakage effects
- To: idn@ops.ietf.org
- Subject: [idn] Specifying leakage effects
- From: Paul Hoffman / IMC <phoffman@imc.org>
- Date: Fri, 11 Feb 2000 10:56:27 -0800
- Delivery-date: Fri, 11 Feb 2000 10:55:41 -0800
- Envelope-to: idn-data@psg.com
The term "leakage" has been used on this list in the past few weeks. It
would be good to look at, because it is a very real concern for any
protocol design. Any change or addition that idn makes to the DNS will leak
to other parts of the Internet. This has been seen over and over in the
history of protocol development on the Internet. The new encoding for idn
names will appear in places other than on wire between resolution clients
and resolvers; the question is what the effect of that leakage will be.
Leakage of text-based encodings will be visually annoying. An
internationalized name part that meant something will mean nothing and will
take up more characters than the original characters. If the idn protocol
has part tagging, a user seeing this will at least know that it is a leaked
name part, but still will have no idea what the contents of the part is.
Leakage of a UTF-8-based encoding to protocols that do not handle non-ASCII
domain names, such as SMTP, will hopefully cause the leaked data to be
rejected (it would be worse from a security standpoint if the data were
mis-directed because of misinterpretation of the domain name). If the idn
protocol for using UTF-8 has an ASCII fallback mechanism, that mechanism
has to be installed in all implementations of all protocols that do not
handle non-ASCII domain names. Leakage to any implementation that has not
implemented the fallback mechanism will still fail.
If the idn is text-based, we have to live with and mitigate the visual
annoyance for users. If the idn is UTF-8-based, we have to be really,
really, really sure that it is designed to mitigate any leakage because of
the much more serious consequences (such as large amounts of lost mail and
failure of PKIX certificates to validate, just to name two protocols). I
propose that the latter is very difficult and is likely to cause much more
damage to the Internet than the former.
Just as it is required for anyone writing a text-based idn proposal to deal
with the effects of leakage, it is incumbent on whoever proposes a
UTF-8-based idn to deal with leakage as well. I think it would be good to
add to the requirements document:
All idn protocol documents must fully detail the expected effects of
leaking of the specified encoding to protocols other than the DNS
resolution protocol.
--Paul Hoffman, Director
--Internet Mail Consortium