Subject: re: draft-ietf-dnsext-simple-secure-update-00.txt

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 08 Mar 2000 10:15:05 -0500

draft-ietf-dnsext-simple-secure-update-00.txt

On section 3 on Policy, I think there is a bit of an over reaction
here.  True, RFC 2137 was way to complex and hard to implement.  But
just saying that ALL update policy is outside of the standard doesn't
strike me as the best design either.  You say it avoids
non-interoperability problems but that is only by ruling it all
outside the area of the standard so that possibly you will always have
non-interoperability and a burden on anyone who has an updatable zone
and wants to move their primary.

Assume that 99% of all KEY based updates could be handled by name
scoped authority to update user RRs only.  In particular I think that
would be adequate to handle the DHCP cases.  Consider the following
straw man proposal: three of the formerly designated "signatory" bits
are zero/ignored but the fourth has the following meaning: if zero,
the KEY can not be used to authorize updates; if one, the default
meaning is that the KEY can authorize DNS name scoped update of user
RRs only, however, this authority can be arbitrarily expanded or
reduced by policy setting at the primary server.  If my assumption was
correct, you would then handle 99% of the update authorization
requirements in this one bit in the KEY RR and such zones could be
freely moved between primary servers that supported the secure dynamic
update standard.  Only in the rare cases where a KEY needs to be
authorized to add/change NS's or be restricted to only doing updates
on alternate shrove tuesdays or it's really important to limit its
authority to TXT RRs or something would the primary server arbitrary
policy configuration mechanism be needed.

I'd also like to suggest a minor rewording of section 1.3 as follows:

1.3 - Comparison of data authentication and message authentication

	Message based authentication, using TSIG or SIG(0), provides
	protection for the entire message with a single signing and single
	verification which, in the case of TSIG, is a relatively
	inexpensive MAC creation and check.  For update requests, this
	signature can establish, based on policy or key negotation, the
	authority to make the request.
	
	DNSSEC SIG records can be used to protect the integrity of
	individual RRs or RRsets in a DNS message with the authority of
	the zone owner. However, this cannot sufficiently protect the
	dynamic update request.

	Using SIG records to secure RRsets in an update request is
	incompatible with the design of update, as described below, and
	would in any case require multiple expensive public key signatures
	and verifcations.

	SIG records do not cover the message header, which includes record
	counts.  Therefore, it is possibly to maliciously insert or remove
	RRsets in an update request without causing a verification
	failure.

	If SIG records were used to protect the prerequisite section, it
	would be impossible to determine whether the SIGs themselves were
	a prerequisite or simply used for validation.

	In the update section of an update request, signing requests to
	add an RRset is straightforward, and this signature could be
	permanently used to protect the data, as specified in [RFC2535]. 
	However, if an RRset is deleted, there is no data for a SIG to
	cover.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
 Carmel, NY 10512 USA                             +1 508-261-5434(w)

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 09 Mar 2000 15:08:25 -0500

>and wants to move their primary.

The main problem with RFC 2137 it is not trivial for resolver to determine 
if the key is allowed to update the data it signed.
The language might be toned down a little bit. 

>policy configuration mechanism be needed.

I think it is premature to anticipate what policies sites will use,
and making any assumptions about X% of updates is counterproductive.
Policy at a site can be much more fine grained than
just name; hosts could be allowed to only update address records but 
not text records etc. 

I think that keeping the policy outside the specification until
this area is better understood is the right thing to do NOW. 
(KISS principle).

	Olafur