Date: Mon, 3 Jun 1996 23:43:31 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <dee@cybercash.com>
To: "Edie E. Gunter" <edie@watson.ibm.com>
Cc: dns-security@TIS.COM
Subject: Re: Secure DNS Dynamic Update draft
In-Reply-To: <9605301543.AA20189@edisto.watson.ibm.com>
Message-Id: <Pine.SUN.3.91.960603232743.29978D-100000@cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

On Thu, 30 May 1996, Edie E. Gunter wrote:

> Date: Thu, 30 May 96 11:43:46 -0500
> From: Edie E. Gunter <edie@watson.ibm.com>
> To: dns-security@TIS.COM
> Subject: Secure DNS Dynamic Update draft
> 
> Using the security scheme outlined in this draft, how does one
> dynamically add a new name to a DNS database?  That is, the name 
> doesn't exist in DNS and I want to send in an update to create 
> it there, so I need to authenticate the update with a KEY of some 
> sort.  Which KEY would that be?  Section 3.1.1 seems to suggest that 
> there would be a wildcard already defined for the zone, and I should 
> have the private part of that key in order to sign my update.  Is
> that correct?  What about the zone key?  If there is a zone
> key defined (and there must be, right?) then can I use it
> to sign an update that creates a new name?

The general idea is to use a wildcard named key to sign an update to add a
new name.  This is not necessarily at the zone level.  You could have
*.foo.zone.tld be the owner name of a KEY RR that authorizes adding inferior
names (such aas bar.foo.zone.tld) where zone.tld is the zone name. 

A zone key is very powerful.  It seem unlikely that you would want to
distribute it to outside entities doing updates.  If the zone owner itself,
who signs the zone, is also doing the updates, there are lots of ways it can
do that, like just signing a new version of the zone. 

> Then, is there anything special about setting up a "user" KEY
> RR for this new name?  I want to allow a user to do further
> updates on that name using its own KEY rather than a wildcard
> or zone key.  Would this new KEY RR being created dynamically
> just be signed by the wildcard key or zone key as above?  This
> would seem to satisfy the requirement that its authority be
> traceable to the zone key, but is there some other subltely
> I'm missing?

The update adding the "user" KEY with a non-zero signatory field would 
probably be signed by a wildcard KEY.  The entry that ends up in the zone 
might or might not be signed by the zone key depending on which mode the 
secure dynamic zone is operating in.  If not signed by the zone key it 
would be signed by the update key.

> It seems that the wildcard key, like the zone key is one that
> you'd want to keep to just an administrator or two.  You wouldn't
> want everyone to have the private part of the wildcard key, or
> they could step on each other's updates using it for authentication,
> right?  So, this would imply that adding new names is something
> that a sys-admin would do and is not something that individual
> users would do on their own.  Is that the intention?

The real zone administrator/owner can just edit the master file and 
re-sign the zone.  If you want them to use dynamic update instead, then 
you can have a zone-wide wildcard KEY they use to sign updates.  But the 
principle orientation of dynamic update is towards having a number of 
agents capable of updating the zone in various limited ways.  The limit 
could be name scope, where the wildcards use names inferior to the zone 
name, or the limit could be by using the "weak" or "unique name" limits 
on keys that can be optionally implemented by secure dynamic DNS 
servers and, if implemented, can eliminate the problem of "stepping on 
each other".

> Edie

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html


Received: from relay.tis.com by neptune.TIS.COM id aa17877; 21 Jun 96 17:09 EDT
Received: by relay.tis.com; id RAA19581; Fri, 21 Jun 1996 17:11:23 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
	id xma019579; Fri, 21 Jun 96 17:10:59 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
	id AA29054; Fri, 21 Jun 96 17:10:58 EDT
Received: by relay.tis.com; id RAA19574; Fri, 21 Jun 1996 17:10:53 -0400
Received: from treetops.commerce.net(204.162.67.5) by relay.tis.com via smap (V3.1.1)
	id xma019570; Fri, 21 Jun 96 17:10:49 -0400
Received: from [153.37.6.41] (pool017.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.17]) by treetops.commerce.net (8.7.4/8.6.4) with ESMTP id OAA11951 for <dns-security@tis.com>; Fri, 21 Jun 1996 14:10:55 -0700 (PDT)
X-Sender: galvin@pop.commerce.net
Message-Id: <v03007104adf0bbe45606@[153.37.6.41]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 21 Jun 1996 17:14:49 -0400
To: dns-security@TIS.COM
From: "James M. Galvin" <galvin@commerce.net>
Subject: DRAFT agenda for DNS Security WG
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

Just in case you haven't noticed, we are having a meeting on wednesday,
June 26, 9am-11:30am.

The agenda for the meeting is:

	agenda bashing and introductions

	status of documents
		DNS Security Extensions - draft-dnssec-secext-09.txt
		Mapping AS Number into the DNS - draft-dnssec-as-map-03.txt
		Secure DNS Dynamic Update - draft-dnssec-update-00.txt

	status of implementations
		TIS DNS security
		TIS dynamic update

		others??

	issues

	next steps
		are we ready to advance secure dynamic update?

See you there,

Jim

----------------------------------------------------------------------------
James M. Galvin                                          galvin@commerce.net
CommerceNet, PO Box 220, Glenwood, MD 21738                  +1 410.795.6882
http://www.commerce.net/                       http://www.eff.org/blueribbon


Received: from relay.tis.com by neptune.TIS.COM id aa22344; 24 Jun 96 10:39 EDT
Received: by relay.tis.com; id JAA15232; Mon, 24 Jun 1996 09:36:53 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
	id xma015217; Mon, 24 Jun 96 09:36:25 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
	id AA18121; Mon, 24 Jun 96 09:36:28 EDT
Received: by relay.tis.com; id JAA15211; Mon, 24 Jun 1996 09:36:23 -0400
Received: from hpheger4.nm.informatik.uni-muenchen.de(129.187.214.24) by relay.tis.com via smap (V3.1.1)
	id xma015150; Mon, 24 Jun 96 09:33:53 -0400
Received: (from unterrei@localhost) by hpheger4.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) id PAA02537 for dns-security@tis.com; Mon, 24 Jun 1996 15:36:30 +0200 (MESZ)
From: Gertraud Unterreitmeier <unterrei@nm.informatik.uni-muenchen.de>
Message-Id: <199606241336.PAA02537@hpheger4.nm.informatik.uni-muenchen.de>
Subject: Implementations ?
To: dns-security@TIS.COM
Date: Mon, 24 Jun 1996 15:36:29 +0200 (MESZ)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

Hello,

does there exist implementations of
the 'dnssec' which are available
outside of USA/Canada?

Gertraud Unterreitmeier


Received: from relay.tis.com by neptune.TIS.COM id aa05300; 26 Jun 96 13:41 EDT
Received: by relay.tis.com; id NAA15910; Wed, 26 Jun 1996 13:43:44 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
	id xma015895; Wed, 26 Jun 96 13:43:16 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
	id AA03647; Wed, 26 Jun 96 13:43:18 EDT
Received: by relay.tis.com; id NAA15890; Wed, 26 Jun 1996 13:43:13 -0400
Received: from treetops.commerce.net(204.162.67.5) by relay.tis.com via smap (V3.1.1)
	id xma015886; Wed, 26 Jun 96 13:43:10 -0400
Received: from [206.167.192.166] (ietf192-166.ietf.risq.qc.ca [206.167.192.166]) by treetops.commerce.net (8.7.4/8.6.4) with ESMTP id KAA05624 for <dns-security@tis.com>; Wed, 26 Jun 1996 10:43:09 -0700 (PDT)
X-Sender: galvin@pop.commerce.net
Message-Id: <v0300740aadf7201bb119@[206.167.192.166]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="============_-1376311195==_============"
Date: Wed, 26 Jun 1996 13:48:17 -0400
To: dns-security@TIS.COM
From: "James M. Galvin" <galvin@commerce.net>
Subject: draft Minutes of DNS Security Working Group
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

--============_-1376311195==_============
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Enclosed below is the first version of the DNS Security Working Group
Minutes.  Comments, questions, and corrections are due by monday, July 1,
at which time they will be submitted for inclusion in the proceedings.

Enjoy,

Jim

--============_-1376311195==_============
Content-Type: text/plain; name="dnssec-minutes.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="dnssec-minutes.txt"

The DNS Security Working Group met for one working group session.  First
item on the agenda was the status of the three documents before us.

draft-dnssec-as-map-03.txt - It was decided to remove this document from
consideration by the working group.  At a minimum, it sets up a
requirement for yet another centralized authority to come into existence
to manage the name space, which would seem to be problematic in today's
Internet.  In any case, there is a very small minority of people
interested in this document at this time.  The area director has
indicated that if there is a group who would like to pursue this work he
will consider a proposal for a new working group.

draft-dnssec-secext-09.txt - The document has been through working group
and IETF last call, and has been reviewed by the IESG.  It has been
revised according to comments received and a new version has been
submitted to the IESG for final review.  We expect the document to be
approved and submitted to the RFC Editor for publication as a Proposed
Standard.

draft-dnssec-update-00.txt - Per our agreement last March, this document
is waiting for implementation experience before we submit it to the
IESG.  Trusted Information Systems expects to complete an alpha reference
implementation prior to the December meeting.  If not, we previously
agreed to submit the document to the IESG anyway, since any further
delay would be counter-productive.

TIS spoke briefly on the status of its implementation.  They indicated
there would be a new release soon (during July).  Also, they have
applied for an export license that would permit the global distribution
of the software, with cryptographic calls but without the cryptographic
software, i.e., it would include calls to RSAREF but it would not
include RSAREF.

John Gilmore and IBM each indicated they have partial implementations.
It was pointed out that Microsoft has an implementation underway but no
one was present from Microsoft to either confirm or deny the activity.

There are no implementations of secure dynamic update at this time.

Three remaining issues were brought to the floor and discussed.  The
results of the discussion are as follows.

First, the DNS security document does not currently include any worked
examples of how to validate public keys.  It was agreed that several
examples of validation, including both to the root and to other trusted
points, be added to the document when it progresses from Proposed to
Draft.

Second, the question was raised as to what the validation policy should
be for the global DNS.  It was agreed that now that we have Secure DNS
we need to better understand the validation process and its
implications.  The Chair took an action item to form a sub-group to
prepare a draft validation policy for the working group to review.  This
document will become an adjunct to the secure DNS specification and
ultimately submitted for consideration as a proposed standard.

Third, it was pointed out that the TIS reference implementation does the
security enhancements in the server, not in the client.  TIS took as an
action item to enhance its implementation to include security support
for the client.

This working group will meet at the Winter 1996 IETF.  At that time we
will review any secure dynamic update implementation experience and
consider whether to advance the secure dynamic update specification.  In
addition, the validation policy sub-group will present a draft document
for review by the working group.

--============_-1376311195==_============
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

----------------------------------------------------------------------------
James M. Galvin                                          galvin@commerce.net
CommerceNet, PO Box 220, Glenwood, MD 21738                  +1 410.795.6882
http://www.commerce.net/                       http://www.eff.org/blueribbon

--============_-1376311195==_============--