Re: I intend to have a document ready for Atlanta on this subject.

[Greg Hudson <ghudson@MIT.EDU>]

On Thu, 2002-10-03 at 21:15, Richard Shockey wrote:
> Actions by the DNS Extensions WG in bringing forward for Proposed Standard 
> "Limiting the Scope of the KEY Resource Record" [RESTRICT-KEY] clearly 
> signal the consensus in the IETF that applications SHOULD NOT directly use 
> the DNS for the storage of keys.

The only consensus was that applications should not use the KEY record
for storage of keys, because that could interfere with DNSSEC itself due
to lack of subtyping.

There was no consensus that application keys should not be stored
directly in DNS; that's a point under great contention.

> A more substantial argument in favor of placing application specific
> keys and security objects outside the DNS infrastructure is that
> typically DNS queries use UDP, however since most security keys or
> digital certificates are large objects, which would require the use of
> TCP, this then places a large burden on the DNS infrastructure that in
> the opinion of most observers is "not a good thing"tm.

If keys cannot be distributed via UDP, then that would have as many
negative implications for DNSSEC itself as it does for application keys
in DNS.  It's true that keys are big and UDP packets are limited, but
one can still fit a substantial number of keys in a single packet at the
moment.

Given the distributed nature of DNS, it is not at all clear that there
is a "large burden" problem.  Only zones which deign to serve key
records would suffer the burden of distributing them.

And based on the discussion I've seen, I don't think "most observers"
hold the opinion you say that do.

> DDDS offers a similar but more flexible and definable infrastructure
> not only for keys but other forms of cryptographic material, such as
> certificates by referencing to pointers through a DDDS infrastructure
> and not storing those keys or security material directly in the DNS.

Unless you store key fingerprints in the DNS (or take some similar
approach), this is not a similar or strictly more flexible approach,
because DNSSEC can no longer be used to authenticate the keys.  Some
have argued that DNSSEC should not be used to authenticate keys, but
that's also a point under much contention.