[ga] Secure DNS

[Sandy Harris <sandy@storm.ca>]

This list's bickering over procedures and constituencies is getting rather
boring, so I thought I'd try raising some other questions.

Probably the most important technical development currently taking place in the
DNS area is the creation of DNS security. For more info see:

http://www.toad.com/dnssec/index.html

Summarizing, the current DNS service is unauthenticated and therefore inherently
insecure. If a Black Hat can reroute DNS query packets or subvert a DNS server,
then he or she can distribute bogus DNS data and all other DNS servers will,
with
the current version of the protocols, accept it as Gospel.

This is an extremely serious flaw, allowing your packets to www.bigcompany.com
to be redirected to a rival firm, or bigcompanysucks.com, or Silicone Sally's
Sexy Site, or ...

The only reasonable fix is authentication of DNS records. This is what is being
worked on. If each DNS record carries a public key signature, then the receiving
DNS server can check that signature before trusting the record. This blocks the
Black Hat's attack and provides an opportunity to raise an alarm and attempt to
track down the perpetrator.

This raises some issues for ICANN.

One question is whether crypto export restrictions apply to this software.
In my view, and that of quite a few others, crypto export rules should have
long since been removed entirely, on all software. See:

http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/exportlaws.html

Even under current US rules, however, the DNS software should be exempt from
such restrictions since it does only authentication, not encryption. The US
gov't, however, have been creating obstacles to distribution. See the first
page referenced above for details.

Methinks ICANN should make a rather pointed public statement about this,
along the lines of the IETF's appropriately numbered RFC 1984:

http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1984.txt

It would be a disaster for the net if gov't restrictions blocked or
seriously delayed deployment of secure DNS. It would also, of course,
be directly contrary to stated gov't concerns about protecting critical
infrastructure, (not that I'm naive enough to think that will necessarily
stop gov'ts from acting stupidly).

If it seems useful, I'll volunteer to write a draft of such a statement. 

Another issue is that security is especially important for the root
servers, the top level servers in ccTLDs, and other widely trusted
servers. ICANN should start now (or have they already and I missed it?)
on actions to ensure that everyone managing such servers put appropriate
procedures in place so that DNS security can be in global use shortly
after the software is ready.

These organisations certainly need to sign records they store and may
need to be able sign their clients' keys. When clients sign records they
have, then the receiving DNS servers will need to be able to validate
the client signatures. The obvious may to do this is via a hierarchy.
Trace up a chain of signatures until you find one you trust. The trust
hierarchy need not be the same as the naming hierarchy, and there need
not be only one root key which an installation trusts, but implementation
and management might be sinplified if these conditions hold.

It appears likely we need an ICANN key and procedures for it to sign
all TLD keys. Are those procedures worked out yet?

Still another issue is how to manage this so that the transition to
secure DNS does not further subvert the net in the direction of
commercial control of essential facilities. There are already serious
concerns about NSI misuse of their position. See for example Auerbach's
discussion of the whois database:

http://www.cavebear.com/cavebear/growl/index.htm

With NSI having recently been bought by Verisign, there appears to be
some risk that they might attempt to arrange things so that users
could have secure DNS services only by buying Verisign certificates.
The protocols do not require this, but their policies and procedures
could attempt to enforce it.

Methinks ICANN should make it quite clear now that this would be
entirely unacceptable, lest a fait accompli appear.
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html