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

["Simon Josefsson" <jas@extundo.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

> 	Title		: Limiting the Scope of the KEY Resource Record

IMO it is a mistake to prohibit core DNSSEC functionality without offering
an alternative for those that want to continue use the deprecated
functionality.

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.

Also, quoting the security considerations:

   This document eliminates potential security problems that could arise
   due to the coupling of DNS zone keys and application keys.  Prior to
   the change described in this document, a correctly authenticated KEY
   set could include both application keys and DNSSEC keys.  If one of
   the application keys is compromised, it could be used as a false zone
   key to create false DNS signatures (SIG records).  Resolvers that do
   not carefully check the KEY sub-type could believe these false
   signatures and incorrectly authenticate DNS data.  With this change,
   application keys cannot appear in an authenticated KEY set and this
   vulnerability is eliminated.

This is a bogus consideration.  A resolver that doesn't use the correct
key for each purpose is broken, and removing one way of getting those
incorrect keys doesn't improve the situation.  This specification does not
fix security problem.  Continuing quoting:

   The format and correct usage of DNSSEC keys is not changed by this
   document and no new security considerations are introduced.

The last statement is plain wrong, prohibiting application key
distribution using KEY records of course has security implications  The
considerations are even major, since any existing security applications
using KEY RRs are made non-compliant.  This should be made clear.  Ideally
a transition plan should be discussed as well.

Suggested new security consideration:

   This specification prohibits storing of application keys in KEY records,
   which has immediate security implications for any applications currently
   using KEY records for this purpose.  However, it is not expected that
   many such applications exists.  Existing application are suggested to
   transition to [APPKEY].

   The format and correct usage of DNSSEC keys is not changed by this
   document, and the security considerations of [RFC2535] still apply.







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