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

[Richard Shockey <rshockey@ix.netcom.com>]

At 09:30 PM 10/3/2002 -0400, Greg Hudson wrote:
>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.

understood.. but I submit it is still a bad idea for no other reasons than 
the UDP vs TCP issue and that N applications may need different keys 
referenced against a single globally unique input string...aka FQDN or SMPT 
address or similar URI addresses such as SIP.

There may be one key derived from mailto:richard@shockey.us and another 
from sip:richard@shockey.us . The opportunistic PKI infrastructure must be 
flexible enough to accommodate both and NAPTR records do that by allowing 
the ABNF syntax for the NAPTR service field to be defined by and listing 
the application protocol the application supports.
as an example..

service-parms = [ [app-service] *("+" app-protocol)]
         app-service   = 1*32(ALPHA / DIGIT)
         app-protocol  = token *[":" token ":" token]
         token   = 1*32(ALPHA / DIGIT)


I have some knowledge of how DDDS is used I co-chair the IETF ENUM WG and 
we have been dealing with this for some time.

http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-01.txt

I will basically argue that there is simply no choice here .. its pointers 
and if you are going to use pointers NAPTR records are the most flexible 
and definable tools we have.



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

Ok point well take but I argue that infrastructure issues must be treated 
differently from applications ..that is my point. Randy Bush has argued 
convincingly, to me at least, that we must be very very very careful how we 
continue to burden the DNS..which means from time to time drawing a firm 
line on what is and what is not acceptable.

I accept and support the notion that the line has been drawn in the DNS 
with application specific PKI and its time to solve the problem associated 
with it.


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

I'm not so sure ..but revisiting the discussion is useful .. the problem 
statement still exists and it is useful and productive work for the IETF to 
resolve.

Again I still submit that pointers are more useful more flexible and that 
the burden is therefore distributed and not placed on the DNS servers which 
has enough to do as it is. Again I support the ongoing admonitions about 
further burdening the DNS. I belive that a strict separation between 
infrastructure uses of PKI and applications is necessary and required.


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

Well the desire and possible requirement for DNSSEC here is obvious but  I 
dont want to say we cannot tackle the issue without it.

Is there a partial level of security acceptable to end users here... do we 
have to end world hunger..or just just a portion of it.

I dont have the answer ..

thanks for your fine comments...


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:richard@shockey.us> or <mailto:richard.shockey@neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<