Re: [idn] impacted systems investigation

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

On Mar 12,  6:00pm, Mark.Andrews@nominum.com wrote:
> > Not so.  We all know the servers can handle 8 bit domain names.  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."
> > 
> 	And this is outside of the servers responsability.

This belief is a recipe for breaking old clients...

> It is the responsability the person entering the data to ensure that it
> 	is in valid and of the clients to ensure that answers are within
> 	the expected range.

Clients should certainly do some checking of data, to ensure against
bad data being inserted by an untrustworthy master or slave
server. However, why should catching servers (which should be more
trustworthy) not do so also, or instead if they are considered
sufficiently trustworthy? Distributing code between all clients for
doing checking (particularly on machines without shared library
support, or ones in which the resolver code is incorporated into
shared libraries with other functions (e.g., libc)) is much less
efficient than doing it in one place, even leaving out the time
savings involved in checking then caching. (To some degree, this is
being done in BIND 9 via the lwres daemon, but that requires client
modifications so that the new "lightweight resolver protocol" is used
instead of the standard DNS protocol.)

> 	Anything else will break clients that expect existing behaviour
> 	like you can have a 0x00 as a octet in a label.

??? Most clients that I am familiar with expect exactly the
opposite... hostnames and other DNS responses are generally treated as
_null_-terminated strings.

> 	BIND 8 had a tri state check-names fail/warn/ignore.

The lack of this in BIND 9 is one reason we aren't upgrading yet, yes.

> 	A future server might want utf8-check fail/warn/ignore.  The default
> 	on the master should implementation dependent.  The slave
> 	and caching servers should default to warn/ignore.
> 	A future server may also want ace-convert.

Going with utf8-check instead of check-names (with the full RFC 1123
checks) will break things, introduce possible security problems,
etcetera... unless a client signals otherwise, only names passing RFC
1123 should be allowed (modulo length modifications - 255 (including
final null) is a reasonable maximum name length).

> 	However all this should really be done outside of the server with
> 	tools that produce RFC 103[45] compatible zone files.

You're again assuming trustworthy (following safe standards) origin
servers; caching servers should certainly do this internally.

	-Allen

-- 
Allen Smith				easmith@beatrice.rutgers.edu