Subject: draft-ietf-dnsext-delegation-signer-00

From: Jakob Schlyter <[email-masked]>
Date: Wed, 27 Jun 2001 17:44:44 +0200 (MEST)

to begin with I'd like to say that I like this draft. separating the
security delegation and the key itself is a good thing. as we no longer
keep the same information in the parent and the child, the question on who
is authoriative for what is clearer - i.e. you will know that the
delegation signer record came from the parent and the KEY from the zone
itself. delegation signer simplifies interaction between the parent and
the child which will make deployment less painful. it also eliminates the
problem with key at apex.

regarding selection of format I prefer the compact format as it will keep
zone size down and is also easier to handle for administrators. the
justifications for the verbose format is only to simplify implementation
and I believe should accept the extra code and few CPU cycles that the
compact format might generate.

there have been some discussion about the naming of the record type. it is
DK in the draft but some people like DKEY. after some discussions I think
I like DS, Delegation Signer, best. after all, it is not a key - it's a
hash of a key (when using the compact format). also DKEY is very close to
TKEY and DK sounds almost like DKEY when pronouced.

	jakob

--
Jakob Schlyter <[email-masked]>                Network Analyst
Phone:  +46 31 701 42 13, +46 70 595 07 94   Carlstedt Research & Technology

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

---

From: Roy Arends <[email-masked]>
Date: Wed, 27 Jun 2001 20:57:20 +0200 (CEST)

> TKEY and DK sounds almost like DKEY when pronouced.

Hear Hear (I agree).

Another argument for using the short format is that a secure resolver is
not going to use the DKEY/DK/DS to verify Sig's (the verbose format
permits this) but uses the DKEY/DK/DS as a pointer to the proper KEY.

I would like to see some discussion on the idea of having a
key-authentication-key (a master-key signs several production keys), this
in light of "DS points to key that signs the keyset" vs "DS points to key
that signs the child zone".

In general there are 3 proposals now. DS, SIG@parent and the current
SIG@child. As I see it, DS is an alternative to SIG@parent, with less of
the operational problems SIG@parent has. Next to that, the proposed
master/production key scheme is interesting.

Regards,

Roy Arends

---

From: Miek Gieben <[email-masked]>
Date: Thu, 28 Jun 2001 13:26:30 +0200

[On 27 Jun, 2001, Roy Arends wrote in " Re: draft-ietf-dnsext-delegation-signer-00 "]
> SIG@child. As I see it, DS is an alternative to SIG@parent, with less of
as the author of sig@parent i must say, i like the idea of DS (let's
stick with that name)

> master/production key scheme is interesting.
agreed interesting, but it adds another level of complexity, do we
want that?  

grtz Miek

---

From: Dan Massey <[email-masked]>
Date: Thu, 28 Jun 2001 13:35:13 -0400

On Wednesday, June 27, 2001 at 05:44PM, Jakob Schlyter wrote:
| to begin with I'd like to say that I like this draft. separating the
| security delegation and the key itself is a good thing. as we no longer
| keep the same information in the parent and the child, the question on who
| is authoriative for what is clearer - i.e. you will know that the
| delegation signer record came from the parent and the KEY from the zone
| itself. delegation signer simplifies interaction between the parent and
| the child which will make deployment less painful. it also eliminates the
| problem with key at apex.
| 

I agree with this and think the last two points are particularly important.
We found that the interaction between parent and child has been
a problem.  SIG@parent helps a lot in this regard, but I think this 
draft improves on SIG@parent.  Keys at the apex has also been a problem 
for us and this draft fixes that as well.  

Also, the compact format in section 2.2.1 seems preferable to the verbose 
format in section 2.2.2.

Dan

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 29 Jun 2001 08:34:54 -0400

I'm starting to prefer the Delegated Signer RR over sig@parent as well.  I
know it adds yet another RR to the security extensions, but the RR solves a
lot of the protocol questions of sig@parent and operational problems of
sig@child.

A bunch of us were talking yesterday at Verisign with Mark Kosters (Jakob,
Roy, Mats, and myself).  There was some discussion of adding a field in the
delegated signer record (DS RR?) to list other security conventions used
with the child in addition to the key hash.  This would be similar to the
RDATA field (in some ways) of the SEC record from Ed's old draft.  I'm
having my doubts about adding that.  Not that it wouldn't be helpful, but I
don't think the resolver can always assume that information is correct in
the real world.  The resolver should assume nothing, and be able to verify a
child's security status when talking to the child and not have to rely on
information from the parent.

But the details of the delegated signer can be worked out later.  The main
point of the DS record - to contain the hash of the child's zone signing
key - is a good one.

Scott
===============================================================
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.nist.gov
===============================================================