Re: [ga] Net security's a losing battle

[Rick H Wesson <wessorh@ar.com>]

Sandy,

If registrars could effect the functionality of zones under .COM then I
might expect them to do some of the things you enumerate below. the
problem is that 78% of all .COM delegations are in some way misconfigured.

I don't understand why a resources mostly utilized for speculative
purposes should become secured, and if most domains are screwed up in some
way what makes you think the resonsible party for the domain is competent
to implement any of your suggested security features?

-rick


On Sat, 29 Sep 2001, Sandy Harris wrote:

> Roeland Meyer wrote:
>
> > |> Currently, DNS is almost completely insecure. All the
> > |> servers just accept whatever another server tells them as gospel.
> >
> > Excuse me. After all that good work, I must object to this. The current
> > system is actually quite good and it's all IP-based, not by name. Iff you
> > build to run a RFC2870 compliant server,
>
> That is a "best current practises" RFC titled "Root Name Server Operational
> Requirements".
>
> > which all zone server operators should at least consider.
>
> So you seem to be saying anyone with primary responsibility for any zone
> should adhere to the high standards documented for root servers. I agree,
> at least in most cases. (I cannot think of any exceptions, but am not
> certain there are none.)
>
> Does ICANN have a role here?
>
> Do the current Verisign contracts for root server management require that
> they adhere to 2870? How is their compliance audited?
>
> What about servers for the TLDs, rather than the root itself? Certainly
> security on them is a concern. Should ICANN require RFC 2870 compliance
> there? What are the contractual and auditing mechanisms for that? Are
> they different for different types of TLD?
>
> Are there security requirements that need to be enforced for registrars?
> Could an attacker with sufficient resources set up a bogus registrar, or
> subvert a legitimate one. and use its privileges to slip bad data into
> root servers?
>
> > You primary zone servers become non-recursive vaults.
> > You should have at least ...
> > Your DNS resolvers should be ...
> > Updates should only be allowed from ...
> > TCP Wrappers should protect ALL systems ...
> > Do not take zone updates except ...
> > do not allow zone transfers, except ...
> > Only use BIND, under *nix, ...
>
> All good stuff. We agree that these things should be done for at least
> most authoritative zone servers.
>
> The question is whether ICANN needs to take steps to ensure that these
> are actually done. This is a question of policies and contracts. We
> know the technology exists and should be applied, but there may be
> work to do getting it applied.
>
> > Now, as to the threat of sniffing, ...
> >
> > In order to intercept queries,or any other packets, one must ...
> > ... This is a classic man-in-the-middle attack scenario. It is
> > amazingly difficult to do.
>
> Yes, but it has been done. Remember the folks who redirected internic.net?
>
> Also note that some of the potential attackers have considerable resources.
> One news story I saw estimated bin Laden's personal fortune at $300 million.
> Most national gov'ts could bring resources far beyond that to bear if they
> decided trashing some other nation's net.infrastructure was a good move.
>
> > I'm sorry, but it has been standard practice, at MHSC, to outfit an
> > ecommerce site with ... Anything less, begs for trouble.
>
> No question, this can be got right, many companies do it well, and some
> security consultants offer good services in these areas.
>
> However, to the extent that ICANN is responsible for the stability of
> the DNS, there are still questions worth asking.
>
> > ... Those who don't do this, or something like it, will feel (have felt)
> > the Darwin-Effect.
>
> How do we ensure that no such failure will trash critcal infrastructure
> that ICANN is responsible for?
>
> > ... Personally, I feel that every packet should use strong encryption
> > and every session should use reasonably strong authentication.
>
> I agree. I would see DNSsec as an important step toward that.
>
> > Many of us have just about given up on the IETF producing anything useful
> > and non-political these days. Short-sighted geeks clash with business
> > requirements (and often disregard the latter).
>
> Yes, and business folk sometimes disregard technical issues or introduce
> unfortunate biases.
>
> > Besides, running DNS, inside of a VPN, obliviates the need for DNSSEC.
>
> Only partly. Securing the communication and authenticating the partner
> is a different thing than authenticating the data you get.
>
> > |> However, methinks ICANN might have a role to play in ensuring that
> > |> the registrars actually act on this in a timely fashion, and that
> > |> Verisign or others do not attempt to hijack the process into becoming
> > |> a marketing scheme for proprietary signature technologies.
> >
> > Yes, that is my fear as well. But, I run a CA too<g>.
>
> Methinks this is an issue worth raising in Marina Del Rey.
> --
> 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
>

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