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

[Greg Hudson <ghudson@MIT.EDU>]

On Tue, 2002-07-02 at 22:53, Edward Lewis wrote:
> As far as application keys, instead of trying to lump keys into the 
> DNS, why not explore certificates?  They don't work?  Engineer them 
> until they do.  By their very nature, certificates are the proper 
> approach.

Gosh, that's a strong statement.

I guess I'll just note that the current widely-known certificate
deployment has no key revocation infrastructure; as a result, bogus
certificates issued for Microsoft could not be revoked except by
deploying new software (with a hardcoded CRL) to every desktop.

I'm not sure that solving this problem is a simple matter of
"engineering certificates."  It may mean scrapping the whole concept of
an offline system.

> But what I do mean to say is that putting a lot of extraneous features
> into the name service - just because it is there - is a patently bad
> approach.

I continue to find this argument to be FUD.

For some applications, such as IPSEC, protecting the key of a host using
DNSSEC is not an "extraneous feature"; it's a core part of determining
that the host you're talking to is really authorized by the naming
authorities to use the hostname you wanted to talk to.  You could use
certificates for the same purpose (as we do today for web servers), but
it will always leave one with the nagging question of whether the
certificate authority agrees with the naming authority on who gets to
use what name.

Saying that DNS is being proposed "just because it is there" is a straw
man argument.  People have given perfectly good reasons to use DNS for
this purpose.

> These tools should do the work that is needed (learning trusted keys,
> managing renumbering of networks) and input the results of that work
> to a DNS server.

Agreed.  But I think the same technique can allow putting keys or key
fingerprints in DNS without adding complexity to the primary DNS serving
software.


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