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

From: "Levon Esibov" <[email-masked]>
Date: Tue, 13 Jun 2000 13:46:34 -0700

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

by the following text

"By default, a principal SHOULD NOT be permitted to make any changes to
zone
data; any permissions SHOULD be enabled through configuration."

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.

I apologize that I didn't notice the issue during the workgroup last
call.

Levon

From: The IESG [mailto:[email-masked]]
Sent: Friday, June 02, 2000 5:34 AM
To: IETF-Announce: ;
Cc: [email-masked]
Subject: Last Call: Simple Secure Domain Name System (DNS) Dynamic
Update to Proposed Standard

The IESG has received a request from the DNS Extensions Working Group
to consider Simple Secure Domain Name System (DNS) Dynamic Update
<draft-ietf-dnsext-simple-secure-update-01.txt> as a Proposed Standard.
This will replace/obsolete RFC2137, currently a Proposed Standard.

The IESG will also consider Domain Name System Security (DNSSEC)
Signing Authority <draft-ietf-dnsext-signing-auth-01.txt> as a Proposed
Standard, updating RFC2535

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the=20
[email-masked] or [email-masked] mailing lists by June 16, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-upda
te-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-01.tx
t

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

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

---

From: Terry Lambert <[email-masked]>
Date: Tue, 13 Jun 2000 16:27:34 -0700

Levon Esibov wrote:
> 
> 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."
> 
> by the following text
> 
> "By default, a principal SHOULD NOT be permitted to make
> any changes to zone data; any permissions SHOULD be
> enabled through configuration."
> 
> 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.
> 
> I apologize that I didn't notice the issue during the
> workgroup last call.

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?

We currently use DNSUPDAT at our NOC (permitting changes to
be made only by a locally running daemon over the loopback
interface, with a private, cryptographically secure protocol
between the client and the NOC) to create names for some
transiently connected machines using dynamic IP address
assignment.

We were very careful to only expose a cryptographically
secured channel, and to limit the protocol on that channel
to prohibit updates except for zones _explicitly_ associated
with the credential passed via the private protocol (we went
so far as to prohibit all updates except for two names in a
zone, in fact).

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

I think this may be a case of giving a customer what they
want, instead of what they need?

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: Brian Wellington <[email-masked]>
Date: Thu, 15 Jun 2000 15:30:00 -0700 (PDT)

On Tue, 13 Jun 2000, Levon Esibov wrote:

> "By default, a principal SHOULD NOT be permitted to make any changes
> to zone data; any permissions SHOULD be enabled through
> configuration."
> 

What do you mean by an authenticated principal?  It sounds like what you
mean is that anyone who has authenticated with the server should be
allowed free range over dynamic updates.  This is an exceedingly bad idea.

If what you mean is that a certain type of authentication token can be
granted which allows free range over dynamic updates, this is a lot
better.  The granting of this token can be considered a form of
configuration, since there must be something deciding whether or not to
grant the token.  Of course, if this was on by default, it would also be a
bad idea.

Changing the draft to allow an open policy by default (even if it is a
SHOULD NOT) doesn't sound like a good idea, since then people might
actually implement it that way.

If I'm misinterpreting what you're proposing, feel free to correct me :)

Brian

---

From: Edward Lewis <[email-masked]>
Date: Sun, 18 Jun 2000 07:58:51 -0400

>If I'm misinterpreting what you're proposing, feel free to correct me :)

I think that the wording should (must ;)) remain the same.  One on hand,
when dealing with issues that are purely security-related (as opposed to
protocol liveness, functionality, etc.) a tighter definition is better than
a looser definition.  (Note - I don't advocate making the definition too
tight just to be secure.)

OTOH, I think Brian is misinterpreting a bit.  Dropping the MUST doesn't
imply that the opposite will be preferred.  Dropping MUST to SHOULD doesn't
mean that the default would be to use an open policy.  Levon is only
arguing that implementers should be given a choice.

Albeit a choice I don't think that implementers need to have...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.