Re: [Design] Re: the KEY debate

["Scott Rose" <scottr@antd.nist.gov>]

----- Original Message -----
From: "Michael Richardson" <mcr@sandelman.ottawa.on.ca>
To: <namedroppers@ops.ietf.org>; <design@lists.freeswan.org>
Cc: "Rob Austein" <sra+namedroppers@hactrn.net>
Sent: Sunday, August 04, 2002 12:53 PM
Subject: Re: [Design] Re: the KEY debate


> -----BEGIN PGP SIGNED MESSAGE-----
> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  so fix subscription addresses! ]
>
> >>>>> "Rob" == Rob Austein <sra+namedroppers@hactrn.net> writes:
>     Rob> There is a specific problem with using the KEY RR type for things
>     Rob> other than DNSSEC's own internal keying.   It's called the
"sub-typing
>     Rob> problem" and has been discussed namedroppers many times before,
please
>     Rob> check the archives if you don't already understand the problem.
>
>   Yes, and obsoleting KEY does nothing to solve this problem.
>
>   We know that it can be solved by one of two means:
>      1) well known naming scheme that lets me ask for just what I want.
>      2) creating a RR for each use.
>

Restricting KEY to DNSSEC only does solve the sub-typing problem - for
DNSSEC.  For everything else that wishes to use the DNS to store keys (IPSec
and SSH are the only 2 that come to mind).  APPKEY faced the same problem -
it just pushed the subtyping problem off to all the other protocols and left
DNSSEC as the lucky one.

Esoteric naming schemes (like SRV) bring an increased chance of admin error
(entering RR) and user error (queries).  A new RR for each application
wishing to use sounds better.  If it is good to restrict KEY to DNSSEC, then
having a separate RR type for any other public key is a good idea too.
Again - we get to avoid the sub-typing problem without resorting to other
tricks like naming schemes.

>   There are various schemes for making the name of #1 be looked up
> first. They are a total waste of time since they just add a needless layer
of
> indirection (I can't ask for just the NAPTR that I need, can I? I have to
> sort through them), and they likely cost another round trip.
>
>   Further, if we decide to designate a well known name for a particular
key
> usage, then there is little reason we can't use "KEY" RR as the format.
>
>     Rob> This is a totally separate discussion from whether putting keys
for
>     Rob> things other than DNSSEC itself into the DNS is a good or bad
idea.
>     Rob> If we stipulate that such keys should use a different RR type,
I'm
>     Rob> relatively agnostic on the subject.
>
>   It is not for DNSSEC people to decide if DNSSEC provides the right trust
> model for another protocol. It is for the designers of that protocol.
>

I think Rob is referring to the ever-ongoing debate every time someone
suggests a new RR type be added to the DNS.  It's not a security debate,
more like a philosophy.  Some argue the DNS is fine to use to support other
protocols in this way, some consider it a bad thing.

I was in camp B.  Now I'm leaning towards camp A.  If some other protocol
thinks that using the DNS is the best way to distribute keys, or other
information, then a new RR might be in order.  I realize that we aren't the
best group to argue what the format of those new RR should be, and that
someone experienced with the protocol in question (IPSec, SSH, whatever)
needs to be included, but someone with DNS knowledge should be included as
well - to make sure it meshes with the agreed DNS spec.

>   That means that DNSSEC may not even provide the right trust model for
> mapping of names to IP addresses for certain end-users!
>
>   Any proposal that removes functionality without offering an immediate
> alternative is a complete and total non-starter.  You later write:
>
>   Rob> If the two halves of this proposal were at equal stages of
readiness,
>   Rob> this would be a reasonable way forward.  Unfortunately, they're
not:
>
>   Until such time as -restrict-key-for-dnssec is massively overhauled to
> remove the baseless FUD which occupies 90%, then I do not agree that
removing
> KEY has any documented justification.
>

Just because this draft restricts KEY to DNSSEC does not mean that there
will never be a way of storing other keys in the DNS.  Just that the DNS WGs
alone aren't the best people to do it.  There needs to be some input from
the designers of other protocols.  First question:  what special information
(besides the key itself) should be in a IPSec DNS RR RDATA?

Scott



--
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/>