Subject: IESG comments on draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Sep 2002 18:16:57 +0200 (CEST)

This document was discussed by the IESG today.
Here are the comments:

Section 2.1 describes some of the differences between Application Keys
and DNSSEC Keys. However, some of the text (e.g., reasons 3 and
onward) use upper case MUST/SHOULD language in a confusing way. I
suspect the intent is to describe what the existing RFCs require from
these Keys, but it would be better to not use that terminology at all
here (since Application keys are being deprecated, it seems odd for
this document to be saying what one SHOULD do when processing them)
and just describe what the differences are in a more reader-friendly
way. For example:

   3.  DNSSEC zone keys are used to authenticate application keys, but
   application keys MUST NOT be used to authenticate DNS zone keys.  A
   DNS zone key is either configured as trusted key or authenticated by
   constructing a chain of trust in the DNS hierarchy.  To participate
   in the chain of trust, a DNS zone needs to exchange zone key
   information with its parent zone [2].  Application keys are not
   configured as trusted keys in the DNS and are never part of any DNS
   chain of trust.  Application key data SHOULD not be exchanged with
   the parent zone.  A resolver considers an application key
   authenticated if it has a valid signature from the local DNS zone
   keys, but applications could impose additional requirements before
   the application key is accepted as authentic.

might be better as:

   3.  DNSSEC zone keys are used to authenticate application keys, but
   by definition application keys are not allowed to authenticate DNS
   zone keys.  A DNS zone key is either configured as a trusted key or
   authenticated by constructing a chain of trust in the DNS
   hierarchy.  To participate in the chain of trust, a DNS zone needs
   to exchange zone key information with its parent zone [2].  In
   contrast, Application keys are not configured as trusted keys in
   the DNS and are never part of any DNS chain of trust.  Application
   key data is not generally exchanged with the parent zone.  A
   resolver considers an Application key authenticated if it has a
   valid signature from the local DNS zone keys. However, applications
   will likely impose additional requirements (outside the scope of
   DNSSEC checks) before accepting the application key as authentic.

Sections 4-6 would benefit from similar changes.

Nits:

The document sometimes capitalizes "Application key" and
sometimes doesn't. Be consistent? (And shouldn't it then be
"Application Key".)

uses "isi.edu" rather than "example.com". I don't have a big problem
with this, but should they switch?

> with a response that contain the www.isi.edu A record and SIG record.
s/contain/contains/

> the SIG and authenticate the www.isi.edu A record.  It is typical not

s/typical/typically/

   record.  Note that by placing application keys in the KEY record, a
   resolver will need the IPSEC, email, TLS, and other key associated
   with isi.edu if the resolver intends to authenticate the isi.edu zone
   key (since signatures only apply to the entire KEY RR set).

s/will/would/? I.e., this document is deprecated application keys, so
this should not be "will" it seems.

  Erik

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Dan Massey <[email-masked]>
Date: Thu, 12 Sep 2002 10:39:08 -0400

Hi,

All of the changes discussed below were made and the new
draft is now available:

   draft-ietf-dnsext-restrict-key-for-dnssec-04.txt

Thanks,
Dan

> and just describe what the differences are in a more reader-friendly

<snip of example text>

MUST/SHOULD terms were removed from this section.

> sometimes doesn't. Be consistent? (And shouldn't it then be

fixed using "application key".

> with this, but should they switch?

fixed using "example.com".

> > the SIG and authenticate the www.isi.edu A record.  It is typical not

fixed

> this should not be "will" it seems.

fixed.