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

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 Nov 1998 22:09:27 -0800 (PST)

> The primary reason is that using secret keys is far easier to both
> understand and implement.

is it easier to *use/deploy* at large scale?

randy

---

From: Brian Wellington <[email-masked]>
Date: Wed, 25 Nov 1998 19:03:13 -0500 (EST)

The primary reason is that using secret keys is far easier to both
understand and implement.  it's also more flexible, since it doesn't force
policy issues into a rigid set of bits in the protocol.

The simple-update draft was intended to replace update2.  That's not a
requirement, though.  If someone wants to use public key secure dynamic
update, they can, but I'd prefer to avoid implementing it.

> refer each other at all, as long as neither is written in an exclusive

That sounds reasonable.  The only real references to update2 in
simple-update are for comparison purposes, and these could easily be
removed.

> source to the same server.

Maintaining a secret key between one client and server shouldn't be any
more complicated than maintaining a user password/passphrase.  The
operator of the client uses an out of band method of communicating the
secret, and it's stored in an inaccessible location on both ends.  The key
can have a fairly long lifetime if it's not used often (updates don't
happen that often).

> draft-ietf-dnssec-update2-*.txt cover many common cases.

Interoperability is not really a concern here.  The client doesn't
implement any policy.  A server looks at a list of preconfigured rules,
and declares whether a key has the authority to make an update or not.  It
doesn't matter if different servers declare policies differently, since
the policy information is not transmitted.

How can we decide what the common case is?  There's no way to enumerate
all possibilities, so why try?  If someone wants to implement a strange
policy, why shouldn't it be allowed?

> policies being applied by the server.

The reason for requiring that a zone key be online is that there must be a
key online that can sign data for the zone, so why not make it the zone
key?  I don't see a real reason to use Mode A in update2, and it does make
the draft much more complicated and difficult to implement.

If mode A was removed, the major difference would be in policy: update2
would define policy based on signatory bits and the key's name, and
simple-update defines policy explicitly.

I'd have to think more about TKEYs derived from KEY records, but I don't
think that it should be required to use TKEY in order to use TSIG.

update2 does mention local administrative policies.  If these exist,
though, how would they interact with the policies described in the KEY
record.  What if they contradicted each other, for example?  The main
reason for only defining server-based policy in simple-update was that if
we can configure policies locally, why not just configure all policies
locally?  Also, if TSIGs are used for authorization instead of SIGS, there
can be no policy in the message itself.

> and will become historic.

If neither had a decisive advantage and only one was implemented, that
sounds like it would be correct.  I'm not sure what will really happen,
though.

> Domain Name System (DNS) Dynamic Update" or the like.

The suggested names don't take into account the differences in policy
management.  neither does 'Simple Update', but at least that doesn't imply
that the only difference is in the use of secret keys.  I'd be willing to
change the name if there was a good reason to, or someone suggested a name
that was more appropriate.

Brian

---

From: Randy Bush <[email-masked]>
Date: Mon, 30 Nov 1998 08:42:50 -0800 (PST)

> I don't see why not.  If DNSSEC is not deployed, setting up shared secret
> keys is far easier that fullscale DNSSEC deployment.  If DNSSEC is
> deployed, using TKEY to obtain shared keys is automated.  For the GSSAPI
> exchange mechanism of TKEY, DNSSEC is not even needed.

presume both are deployed (this is a standards discussion).  given a few
hundred thousand zones over a few thousand sites, how easy will it be to
actually set up (as in create and exchange keys etc.) and operate tsig
vs. dnssec?  for the (sometimes purposfully) naive of us, it might be
helpful if someone would describe the difference from an operational
perspective.

randy

---

From: Brian Wellington <[email-masked]>
Date: Mon, 30 Nov 1998 11:19:48 -0500 (EST)

Speed can also be a concern when dealing with a heavily used server, and
TSIG operations are much faster.

I should probably also mention that TSIG support will hopefully be in the
next version of BIND, while full DNSSEC is at least a year away.

Brian

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 30 Nov 1998 10:47:22 -0800

> helpful if someone would describe the difference from an operational

TSIG presumes a smaller number of relationships, either because a
collection of local LAN or campus clients "knows" its caching forwarding
resolving nameservers, or because a collection of DHCP servers "knows"
its associated in-addr DNS zone authority servers.

DNSSEC presumes only relationships between zones and their parents, with
"." being the crossroads of last resort for two parties to learn each other's
keys in a secure fashion where no direct relationship preexisted.

it is easier for a campus or entreprise network to get started with TSIG
than with DNSSEC.  this is more true now than it will be after DNSSEC has
been rolled out worldwide, but it will always be true to some extent.

---

From: Randy Bush <[email-masked]>
Date: Mon, 30 Nov 1998 14:08:20 -0800 (PST)

> been rolled out worldwide, but it will always be true to some extent.

so, tsig scales well as a campus or organizational solution.  and dnssec
scales well to the global internet?

randy

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 30 Nov 1998 15:57:21 -0800

> so, tsig scales well as campus or organizational solution.  and dnssec

if by "scales well" you literally mean "if it were used on all nodes", yes.
but, your recharacterization loses one important aspect of mine, which is
that the goodness of these solutions are each exclusive to their sweet spot.
that is, neither one of these solutions would be good in both situations.