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

[Jeff Williams <jwkckid1@ix.netcom.com>]

Sadny and all assembly members,

  Sandy, if you have been paying attention of goings on in the IETF
you would know that Todd is already a member of the IETF
presently and an active participant...

Sandy Harris wrote:

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

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-244-3801 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


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