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

From: "Simon Josefsson" <[email-masked]>
Date: Tue, 2 Jul 2002 13:36:29 +0200 (CEST)

[ 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Greg Hudson <[email-masked]>
Date: 02 Jul 2002 13:42:26 -0400

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

> an alternative for those that want to continue use the deprecated

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."

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Jul 2002 11:20:42 -0700

> 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).

ack

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

quibble: if we get consensus to put them in, i presume that they
would be authenticated with normal dnssec mechanisms.  i.e. the
latter should not be an issue.

> We do seem to have consensus that KEY is a bad way to put keys in

indeed, i believe this draft did pass wg last call.  this version
was a touchup to answer nits raised by the area director before
passing to the iesg.

> 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."

it is my impression that this is what is occurring.

randy

---

From: Rob Austein <[email-masked]>
Date: Tue, 02 Jul 2002 14:33:08 -0400

> importantly, name-to-address and address-to-name mappings).

Bingo.

> quickly exceed the EDNS0 UDP packet size limit and eventually exceed the

This is the so-called "subtyping problem".  In brief: conceptually, an
RRset is named by TYPE + NAME + CLASS, where "+" denotes (conceptual)
concatenation.  When such an RRset gets too big and all the RRs in
such an RRset are (conceptually) related, there's not much one can do
about it (this is part of the reason why MG RRs never caught on), but
when the RRs that make up such an RRset make up two or more
conceptually distinct groups that can only be identified by fetching
and examing the whole RRset (and, most likely, discarding the
irrelevant portions), it's the subtyping problem.

All the known ways of getting out of the subtyping problem involve
breaking the big RRset up into seperate RRsets by changing the
conceptual name (somehow).  The two common ways are either to use
separate TYPE codes or to use magic labels at the least significant
end of the NAME.  Which solution one prefers depends on how easy one
believes it is to add new TYPE codes to the DNS (opinions vary) and
how much one wishes to avoid using magic labels (opinions vary).

My understanding is that most (all?) of the folks proposing to use a
single APPKEY TYPE also propose to use the magic label approach.

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 2 Jul 2002 14:55:47 -0400

The main reason no alternative was bundled with the restrict-key draft was
because we didn't have any consensus about how to store keys in the DNS, but
a general consensus that the KEY RR was a bad choice.  In fact an entire BOF
was spawned to address a general version of this problem (SIKED).  Besides
APPKEY, there are a few other competing proposals if I remember.

So how non-DNSSEC keys are still being debated on, we decide to at least
take the KEY RR out of the running and leave the subject of securing DNS
separate than using DNS to support other security transactions.

Scott

---

From: "Andy W. Barclay" <[email-masked]>
Date: Tue, 02 Jul 2002 12:24:45 -0700

>>importantly, name-to-address and address-to-name mappings).

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.
`----

> irrelevant portions), it's the subtyping problem.

Yes, this could be a problem, IF you have a lot of keys at one name.
I envision that additional names will be created for most
applications. If we assume 1k per key (which I don't feel is 
unreasonable, but I could be wrong here), then we can store 
approximately 60 keys at a single name before we overflow.

> single APPKEY TYPE also propose to use the magic label approach.

Neither of these is necessary if we can live with the 60 keys per DNAME
restriction. I don't think this is overly-restrictive. Its just like we 
all deal with limitations on number of type A RRs associated with a name
so that the query/response doesn't fall over into TCP which a huge 
number of name servers would fail on anyway (cause silly admins block TCP).

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

Give a small boy a hammer and he will find that
everything he encounters needs pounding.
    --ABRAHAM KAPLAN

---

From: Rob Austein <[email-masked]>
Date: Tue, 02 Jul 2002 16:45:07 -0400

> |    protocols.  Provision is made for a variety of key types and

The WG said a great many things in RFC 2535, some of which have held
up better than others under further scrutiny as the WG has continued
its attempts to understand the problem space.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Jul 2002 00:05:47 +0200 (CEST)

> single APPKEY TYPE also propose to use the magic label approach.

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:

 host.example.com. NAPTR 1 10 "p" "APPKEY+ipsec" "" ipsec.host.example.com.
 ipsec.host.example.com. APPKEY ...

	jakob

---

From: Robert Elz <[email-masked]>
Date: Wed, 03 Jul 2002 10:24:30 +0700

Date:        Tue, 02 Jul 2002 12:24:45 -0700
    From:        "Andy W. Barclay" <[email-masked]>
    Message-ID:  <[email-masked]>

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

[email-masked] 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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Jul 2002 22:53:43 -0400

I don't intend this statement to be directed at any individual, but 
the following mail fragment is what prompted my statements below.

At 12:24 PM -0700 7/2/02, Andy W. Barclay wrote:
>>>I don't think application keys in DNS is "core DNSSEC functionality." The
>>>core DNSSEC functionality is protecting existing DNS data (most

I agree with Rob's and Randy's (not shown) thoughts on this thread.

Speaking as someone who has spent considerable time on DNSSEC, who 
co-chaired the BOF on SIKED, and was a closet proponent of A6, DNAME, 
and binary labels, I would say now that - to stay to the subject at 
hand - placing unadorned application keys in DNS is a mistake.

Way back before I spent time in the IETF, I developed a name server 
prototype.  The project I did this for is not historically 
significant, but I learned a lesson then that I had forgotten in my 
(later) formative years. (I have since relearned it from Randy at the 
SecDynUp workshop last winter).  Name service ought to be a simple, 
humble component in the machinery of a network.  Much like any 
central piece of a distributed system, the name service must be built 
to be rugged, flexible, and resilient.

Does this mean that the name service should not be secured, a la 
DNSSEC?  No.  Security is part of resilience.  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. 
Sure, it is tempting to leverage on the service in place, but in the 
long run we wind up making the protocol more complex and worse, by 
putting all our eggs in one basket, create a more critical single 
point of failure.

RFC 2535 (and its predecessor) were wrong to promise that DNSSEC 
would be a fine way to distribute keys.  (I don't fault the editor, 
it was WG consensus at one time.)  Key distribution is a matter best 
left to the certificate working groups.  Why let the distributed 
database folks create another trust model when this is being done by 
security folks?  So what if there is unhappiness with what has been 
produced to date - those unhappy aren't going to do a better job than 
security experts.

I don't want to tie in the IPv6 record debate - that's another 
document, another thread, and a different last call.  But (I will 
because) the reason behind my distaste for this kind of DNS 
innovation is that these are (worthy) problems that ought not be 
solved in the DNS protocol.  What is needed is better (software) 
tools, applied in the right places.  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.  The 
DNS server should then simply distribute the data, and nothing more. 
Securely distribute - but only guaranteeing that what went into the 
master zone is what comes out the resolver.  No application security, 
just end-to-end transit security.

Keep the DNS simple.  Use it to locate other services.  Let other 
services update the DNS.  But don't make the DNS do too much - even 
if it is the path of least resistance.  Remember what the E in IETF 
stands for, it's not the "Internet Path of Least Resistance Task 
Force."  Fix what's broken, don't overload the protocol.  Complexity 
is a cancer.  Creeping features are a carcinogen.

So much for a soapbox statement.

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.  If it is because the tools aren't available - make the 
tools.  Don't break a fine protocol like DNS.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Greg Hudson <[email-masked]>
Date: 03 Jul 2002 09:50:38 -0400

On Tue, 2002-07-02 at 22:53, Edward Lewis wrote:
> 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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2002 11:45:04 -0500

Maybe this is a stupid question, but in what way does putting application 
key records into the DNS make it more complicated?   Does it *need* to be 
more complicated, or is this a bug in the specification that could be fixed?

I agree with you that adding *complexity* to DNS is a bad thing.   I just 
don't see how that premise directly supports the argument that there should 
be no keys in the DNS.   That is, adding *complexity* to the DNS is not the 
same thing as adding *records* to the DNS.   There is no reason why records 
have to be complex.