Re: [ga] Solution to one problem,perhaps...

[Sandy Harris <sandy@storm.ca>]

todd glassey wrote:
 
> Has anyone ever thought about ... creating a
> reasonably specific set of requirement
> statements and sending them as an implementation
> request to the IETF...

I don't think it does or should work that way. If
you want to influence the IETF process, join their
working groups, or talk to the people who have.

> ... with request for a next generation version
> of DNS we can fix the things that are cumbersome
> in operating a Registrar or Root Zone Service...

That would be the DNS operations WG:
http://www.ietf.org/html.charters/dnsop-charter.html

> heck we could add things like a Domain Revocation
> Control Process for real-time shutdowns and the
> like...

It isn't at all clear we need that. After all, it 
is pretty simple now. Delete a few records and wait
for changes to propogate. Sure a tool for that
might be handy, but that doesn't need protocol
changes. Just go write the tool.

If you want to make it "real-time" in the sense of
avoiding propagation delay, immediately killing
data that may be held in caches anywhere on the 
net, I think you're out of luck. Unless I've badly
misunderstood something pretty basic, you cannot
do that short of rewriting DNS from the ground up
and it isn't clear that a rewrite to that spec is
possible, let alone desirable.

Anyway, the hard issues for domain revocation are
questions of policy, not mechanism. Who gets
revoked? Spammers? Trademark violators? Terrorists?
Pornographers? Who makes revocation decisiond, and
how? and so on ...

> This would also provide an interesting and new
> vision on how the management team reacts to the
> IETF/IESG/IAB's just ramming another protocol
> out onto the Internet without bothering to figure
> out what its impact or liabilities are...

ROFL.

> And since today's Internet is not a test bed but
> a commercial production network, maybe it needs
> to be treated as such.

It is. Look at an archive of any WG list to verify
the players' affiliations.
 
> My motion then to this GA is that we create a small
> WG to study and report of the possibilities for
> adding services into the DNS environment for
> enhanced security and to make a recommendation to
> the IETF that they charter the DNS WG to implement
> this as per our specifications or to work with us
> on perturbations.

The IETF created a DNS security WG some time ago.
It has since been re-arranged, so the relevant
page is now:
http://www.ietf.org/html.charters/dnsext-charter.html

Why on Earth would you imagine we can do this better?

I do think there might be a role for us in getting
DNS made more secure, but it is nothing like what
you suggest.

Basically, how you make DNS secure is by putting
public key signatures on DNS data so the recipients
can verify your authority for tha data,

So, should we be pushing ICANN to get root zones
signed, to include key management practice in the
things registry contracts cover, and so on? I'd 
say, emphatically yes, though it isn't clear that
this is urgent yet. It may not matter until there
are more servers ready to use the information.

Also, one of the major obstacles to deployment of
Secure DNS is that the .com zone is too large. If
you try to sign it, you hit several problems. The
records get a lot bigger, so the servers run out
of RAM, have to use disk, get much slower, ...
Also with several million records in .com, it is
expensive to sign it and perhaps prohibitively
so to keep signatures up to date.

So perhaps we should be looking at whether to
stop new .com registrations, revoke unused ones,
whatever. Of course this is tied to questions of
when and how to deploy alternatives.

In my view, if security is actually ICANN's most
important problem, as various peoplem proclaimed
when re-arranging the meeting agenda last fall,
then knocking .com down to manageable size should
be our top prority.
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html