Subject: RE: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard

From: "Levon Esibov" <[email-masked]>
Date: Thu, 15 Jun 2000 13:41:23 -0700

> Levon Esibov wrote:
> >=20
> > I'd like to recommend to replace the text fragment from
> > Section 3 "By default, a principal MUST NOT be permitted
> > to make any changes to zone data; any permissions MUST be
> > enabled though configuration."
> >=20
> > by the following text
> >=20
> > "By default, a principal SHOULD NOT be permitted to make
> > any changes to zone data; any permissions SHOULD be
> > enabled through configuration."
> >=20
> > I believe the decision on the default configuration should
> > be left to implementers. The deployment experience of Beta
> > Windows 2000 demonstrated difficulties that administrators
> > experienced in configuration of the zones for the dynamic
> > updates. It was found that the default configuration that
> > satisfied majority of customers is to allow all the
> > authenticated principals to create new names in a zone,
> > but prohibit any unauthorized principals from modifying
> > the existing records. This is the default configuration of
> > the Windows 2000 DNS server.
> >=20
> > I apologize that I didn't notice the issue during the
> > workgroup last call.
>=20
> If you make this change, shouldn't there be a corresponding
> change to the "Security Considerations" section to note that
> this permits an authenticated principal to stage a denial of
> service attack against other authenticated principals, by
> creating names in a zone that another principal was going
> to create?

> What you are proposing seems to open a very bad security
> hole that we were very careful to avoid (going so far as
> to use a private protocol, given that DNSSEC is not really
> ready for deployment in a customer environment yet).

1. I agree that this permits an authenticated principal to stage a
denial of service attack against other authenticated principals, by
creating names in a zone that another principal was going to create.
That's why I am not claiming that such default configuration should be
recommended/required by this RFC. I'd like to emphasize that all I am
recommending is that the RFC doesn't require what the default
configuration MUST be, but makes a recommendation on what the default
configuration SHOULD be.
i.e. "By default, a principal SHOULD NOT be permitted to make any
changes to zone data; any permissions SHOULD be enabled through
configuration."

Implementers should be able to make there own decision on the default
configuration depending on the environment where their DNS servers are
used. For example, in the corporate environment a principal that
generated the denial of service attack (that you described above) will
be easily identified and fired. Thus our default configuration may be
not only what the customer want, but also what the customer needs.

2. I don't think that the proposed modification (replacement of MUST by
SHOULD) requires any modifications of the "Security Considerations". It
is so because if the "Security Considerations" section doesn't need to
describe the potential security issues when admin changes configuration,
then there is no need to describe the potential security issues when DNS
server implementer decides to change the default configuration. But I
don't have strong objections against adding clarification
sentence/paragraph  to the "Security Considerations". If majority on the
namedroppers believes that we should update the "Security
Considerations", I'd be glad to volunteer to do it.

Thanks,
Levon.

Levon Esibov
Program Manager
Microsoft Corporation

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 18 Jun 2000 18:35:02 +0200

>changes to zone data; any permissions SHOULD be enabled through

two possible readings of your text:
1) you recommend that principals authenticated in the msn.com domain should
be able to insert records in the exchange.microsoft.com zone.
This doesn't seem likely.

2) there is a missing piece that says that an unconfigured DNS server is 
able to find out which zone it has as its primary authentication domain, 
and verify authentications for other prinicipals in that zone, all without 
configuration, and that you think this should be allowed by the RFC.

If you will grant that installing a DNS server in a Win2000 authentication 
domain involves "configuration" telling it which domain that is, I think 
you are conformant to the letter of the RFC as currently written.

                      Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]