Re: [idn] impacted systems investigation

[Mark.Andrews@nominum.com]

> On Mar 12,  7:06am, David C Lawrence wrote:
> > Mark Andrews said:
> > > UTF8 does not require a server upgrade
> > 
> > D. J. Bernstein answered:
> > > Right. But Patrik and Paul claim the opposite. This claim is, in fact,
> > > the centerpiece of the IDNA ``design philosophy.''
> > 
> > Not so.  We all know the servers can handle 8 bit domain names.
> 
> Incorrect, at least if they are using domain names for, for instance,
> filename construction - which is currently the case for BIND 9 in
> DNSSEC, for instance. I have submitted a patch to bind9-bugs@isc.org
> to help solve this problem.

	It's not a server bug, those parts of the library are not called
	by the server.

> 
> > What the servers can't tell, however, is whether some 8 bit string is UTF-8
> > or some local encoding, and that presents a security problem.  To use
> > UTF-8 at the server, the protocol would need to be updated so that a
> > client could affirmatively declare, "I'm IDN-aware, and thus my
> > request is using UTF-8, not some other local encoding."
> 
> Agreed. Unless a client affirmatively declares this, returning names
> outside of RFC1123 standards should not be done, for many security
> reasons.
> 
> 	-Allen

	It's not the servers job to enforce this.  This is not new.  As
	a problem it exists today.  IDN does nothing to change this other
	than (if we go with utf8) increase the number of names returned
	/ used that fall outside of RFC952/RFC1123.

	Part of the problem with the utf8 solution space is that those
	clients (OS's) that cared about security need to be updated to
	the new spec.  Those that didn't are just as vulnerable as they
	were before, just that they are more likely to recieve data
	they are not prepared for.

	Mark
> 
> -- 
> Allen Smith				easmith@beatrice.rutgers.edu
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@nominum.com