Re: [idn] impacted systems investigation

["Allen Smith" <easmith@beatrice.rutgers.edu>]

On Mar 23,  2:22am, Mark.Andrews@nominum.com wrote:
> 
> > 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 about bin/named/tkeyconf.c?

> > 
> > > 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.
> >
> 
> 	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.

I'm not quite sure what you're meaning here. Clients that care about
security should indeed be updated to make sure they reject
non-RFC952/RFC1123 names (with escaping any characters outside that
set another possibility, although it admittedly does introduce the
escape character (which, normally being \, could cause problems on
machines using that as a directory separator)). Or were you meaning
that OSes that _did_ this should be updated to allow utf8 characters?
That "solves" the problem for the OSes, but not for applications...

> 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.

We use a bind-8 caching-only server with check-names fail. As long as
requests are going only to this server or other, trusted servers, this 
does indeed protect the clients. Maintenance of this capability is of
importance (it's one reason we haven't moved to bind-9), and is of
significance for IDN.

	-Allen

-- 
Allen Smith				easmith@beatrice.rutgers.edu