[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




Rob Austein wrote:
At 02 Jul 2002 13:42:26 -0400, Greg Hudson wrote:

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

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



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.

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


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.
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. abarclay@unixpeople.com
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


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