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

[Greg Hudson <ghudson@MIT.EDU>]

Speaking as someone who thinks it would be cool to protect keys using
DNSSEC:

On Tue, 2002-07-02 at 07:36, Simon Josefsson wrote: 
> IMO it is a mistake to prohibit core DNSSEC functionality without offering
> an alternative for those that want to continue use the deprecated
> functionality.

I don't think application keys in DNS is "core DNSSEC functionality." 
The core DNSSEC functionality is protecting existing DNS data (most
importantly, name-to-address and address-to-name mappings).

We don't have consensus on whether or not it's a good idea to put keys
in DNS or to protect them with DNSSEC.  As such, it is hard to progress
proposals which fix the problems associated with doing it the RFC 2535
way.

We do seem to have consensus that KEY is a bad way to put keys in DNS. 
It seems reasonable to say, "Don't do it this way; we will continue to
argue about whether we should be helping you to do it at all."

> Suggestion: Ship restrict-key-for-dnssec together with the APPKEY spec,
> assuming the scope of APPKEY is made the same as KEY-for-application was.

I have doubts that APPKEY is practical, by itself.  It seems that if you
have many applications with keys at the same domain name, you will
quickly exceed the EDNS0 UDP packet size limit and eventually exceed the
hard 64K limit.


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