Re: [idn] Re: 7 bits forever!

["David Leung \(Neteka Inc.\)" <david@neteka.com>]

> Valdis.Kletnieks@vt.edu writes:
> > you could *NOT* trust that all the systems
> > between here and there were 8-bit-clean
> > there were a *LARGE* number of systems that broke badly if they
> > were handed 8 bit data.
>
> Let's look at the facts. John Klensin claimed in an ietf-smtp message
> dated 26 Feb 91 08:40:04-EST that there were mail servers ``not robust
> against that particular form of misbehavior.'' Robert Ullmann publicly
> asked for proof of this claim. Klensin dodged the question.
>
> Similarly, Keith Moore claimed in a comp.mail.mime message, message ID
> 199710102108.RAA13469@spot.cs.utk.edu, that ``core-dumping was a
> commonly observed failure mode in the early 1990s.'' I publicly asked
> for proof of this claim. Moore dodged the question.
>
> Mail servers discarding characters? Yes. Mail servers stripping the 8th
> bit? Yes. Mail servers crashing? Not a single shred of evidence.
>
> Similarly, expanding from mail to all protocols: Rick Wesson claimed in
> an IDN WG message dated Sun, 24 Dec 2000 16:44:39 -0800 that ``there is
> a lot of embedded systems out there that would crash-and-burn if they
> received a reply in utf8.'' I asked for proof:
>
>    Can you please identify the systems, explain how they use domain
>    names, and say what exactly you mean by ``crash-and-burn''? We need
>    this information if we're going to accurately assess the cost of
>    upgrading the world to support IDNs.
>
> Naturally, Wesson dodged the question.
>
> I will readily agree that there has been an unverified report of a UTF-8
> crash of an obsolete version of the Netscape mailer under Solaris. If
> that report is accurate then those users will have to upgrade.
>
> > BIND, which by default restricts it
>   [ ... ]
> > Why does it get restricted?
>   [ bogus rationalization snipped ]
>
> The actual history, as I mentioned in another message, is as follows.
>
> People discovered several years ago that sendmail would blindly feed DNS
> PTR results to the shell, so attackers could take over the computer by
> putting some special characters, such as |<>, into PTR records. The BIND
> people panicked and disabled all non-letter-digit-hyphen characters at
> every spot they could think of in their DNS client library.
>
> This isn't an 8-bit issue; it does just as much damage to underscores.

I totally agree on what DJ Bernstein said, I have been look for proofs
everywhere to see how 8bit characters can "crash-and-burn" things, but wasnt
sucessful in finding any proof.

Core-dumping is the result of bad software design, and not from 8bit chars,
if you claims that 8bit chars will crash certain software, why? because you
haven't allocate enough memory for the variables that will be fed with
8bits, but I cannot find a variable type that represents 7bits and 8bits
differently, char? short? maybe on some VERY VERY LEGACY system there
maybe?!

If attackers found ways of using 8bits to crash systems or gain control of
systems, that is usual because hackers and attackers exploit security holes
in softwares, and it should be considered as a security hole and not an IDN
problem!! Moreover it should be the issues of FBI and the law enforcers and
not the issues of using IDN as 8bit or not...;>

> > Let's take as an example the "native language" encoding of my name:
> > From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks <Valdis.Kletnieks@vt.edu>
>
> Wow. How do you pronounce that? ``Hi, I'm Valdis Klee-kwals-question-
> mark-iso-eighty-eight-fifty-nine-dash-four-question-mark-kyoo-question-
> mark-equals-bah-question-mark-equal-stun-ieks''? Have you considered
> changing your name?
>
> In all seriousness: Wouldn't you like to see a world where the same
> character encoding is used for the name and the address and the message
> body and so on, so that simple copying doesn't screw up the display?

100% agree why can't we use 8bits with new ESMTP commands and MIME header
that retains the names as is!!

David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com