Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Tue, 02 Jul 2002 12:24:45 -0700
    From:        "Andy W. Barclay" <abarclay@unixpeople.com>
    Message-ID:  <3D21FDFD.5060005@unixpeople.com>

  | I disagree. RFC 2535 is very clear on this point, as I was reminded
  | a few weeks ago when I questioned why we bother with DNSSEC at all.
  | 
  | |    Keys associated with DNS names can be retrieved to support other
  | |    protocols.  Provision is made for a variety of key types and
  | |    algorithms.

That says that you can use the KEYS that exist for other protocols
if you feel inclined.   It doesn't say that you can add new ones for
some other purpose...

The variety of key types, etc, is in case DNSSEC needs/wants to change
the algorithms it uses for securing the DNS.

  | Yes, this could be a problem, IF you have a lot of keys at one name.

The only way to avoid that is as Rob Austein said - magic names, or
different types.   Magic names are absolutely the wrong way to use the
DNS - the namespace there is to be allocated to the end user organisations
to use as they see fit, not to constrain for protocol purposes.
(You can see that I have one of the opinions that Rob mentioned...)

  | Neither of these is necessary if we can live with the 60 keys per DNAME
  | restriction.

That means < 30 applications max (to allow each to have a current, and
a past, key visible).   That's a very very low limit.

And ...

jakob@crt.se said:
  | one could use a naming based on napstr, that would remove the magic
  | label approch for appkey but move it to a reference inside an naptr
  | instead. perhaps something like:

That isn't a solution, it is the problem itself.   That's exactly what
needs to be avoided (for some particular cases it may be possible to
work that way, and NAPTR might happen to be one of those, keys certainly
aren't).

kre


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