Subject: draft-ietf-dnssec-simple-update-00.txt

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 18 Nov 1998 09:36:00 -0500

I have no particular problem with secret key (TSIG) secure dynamic
update.  I just don't see any reason it has to blow away public key
(SIG) secure dynamic update. In fact, in
draft-ietf-dnssec-update2-*.txt I tried to add changes that clearly
allow secure update based on negotiated permissions and policies
embodied in TSIG.

Quite possibly it is a better idea to have separate secure update
documents for these two methods and I'm not even sure they need to
refer each other at all, as long as neither is written in an exclusive
fashion.

While I'm sure there will be lots of dynamic update secured by TSIG,
I'm not at all sure that the overall system will be any simpler than
using SIG.

Configuring and maintaining a bunch of secret keys directly would be a
tremendous pain and not good cryptographic practice so I think that in
real world cases of any size, you would usually set up the secret keys
with TKEY (draft-ietf-dnssec-tkey-01.txt).  Thus, in the case of
occasional updates, you would have just as much computation and more
round trips with TSIG compared with SIG.  TSIG based update is, of
course, much better when you have frequent updates from the same
source to the same server.

On policies, it may seem simpler to just declare policy to be
unspecified proprietary stuff but I don't think that helps
interoperability much.  I think the policy options in
draft-ietf-dnssec-update2-*.txt cover many common cases.

One thing that draft-ietf-dnssec-simple-update-00.txt does is require
that the zone key always be on line.  This is less secure but simpler
than the case where the zone key can be off-line, which is allowed by
draft-ietf-dnssec-update2-*.txt (which covers both cases).  If there
is a WG consensus that it is reasonable to always require the zone key
be on line for dynamic zones, it certainly woulnd't be hard to
eliminate Mode A from update2 and doing that eliminates the more
complicated parts of the optional to implement interoperable policies
it provides.  At that point, update2 would moslty just define the
scape of the DNS names that a dynamic update KEY could have authority
over.  I think that's pretty reasonable and I would think that, by
default, having secret keys that are derived from those update KEY RRs
via TKEY having the same scope of control, to the extent permitted by
server policy, would be natural. Since update is implemented at the
server, the server has control over what can be changed anyway and
there are references in update2 to additional local administrative
policies being applied by the server.

Really, these two drafts are not as far apart as they might seem,
although one is public key based and, I think, best for occasional
updates, while the other is secret key based and, I think, best for
frequent updates.  People should keep in mind we are still just at the
Proposed Standard level here.  If both are issues as Proposed and only
one is implemented, presumably the other will not progress to Draft
and will become historic.

I suggest that this draft be re-named "Secret Key Secure Domain Name
System (DNS) Dynamic Update" or "TSIG Secure Domain Name System (DNS)
Dynamic Update".  I'd be happy to remove the TSIG stuff from
draft-ietf-dnssec-update2-*.txt and rename it "Public Key Secure
Domain Name System (DNS) Dynamic Update" or the like.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)
 Carlisle, MA 01741 USA