At 08:04 PM 8/30/2004, domainkeys-feedbackbase01(_at_)yahoo(_dot_)com wrote:
--- Richard Shockey <richard(_at_)shockey(_dot_)us> wrote:
> On a related subject ..I'm assuming that there is
> already general consensus
> that the use of TXT for storing public keys as
> described
>
>
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt
>
> shall be considered harmful.
I don't think that's entirely clear at all.
It depends on whether you're asking the question as to
whether DNS is the right place for storing such
material in the short or long term and whether TXT is
the right type in the short or long term.
What I'm saying is that A. the DNS is NOT the right place for directly
storing such material period irrespective of the underlying RR. This was
the principal problem we saw in the DNSSEC debates and that time it was
made quite clear that cryptographic material not directly related to the
proper, secure functioning of the DNS should not be stored in the DNS.
The short term vs long term issues are IMHO relevant. I belive this
argument has already been decided and the IAB and IESG will not accept
further specifications that are based on the use of the TXT RR with the
singular exception for MARID for the well know reasons outlined in the San
Diego meetings.
I believe the answer to those four points can all be
different.
>
> I've often thought it was time to start thinking of
> using NAPTR records for
> such things as PKI since the represent the most
> powerful and flex able RR
> records we have as in for instance and now would be
> a good time to start
> using them as in, for example.
Above and beyond relevance of the feature-set of NAPTR
to this application, is the question of whether
indirection through the DNS to a TCP based content
server create too high an impact on the Internet at
large.
Please ... see RFC 3761. If we have agreed we are using the DNS to
essentially set up every phone call on the planet ( two look ups BTW, TN to
URI and then URI to SRV ) and our bizarre friends in the product goods
industry have decided they want to do a DNS look up ( the Object Name
Service) to find product information on every soup can on earth....
http://www.epcglobalus.org/Network/how_works.html
have already overloaded the Internet at large and additional look ups for
PKI material is not going to do any more damage.
Some claim that even a single additional DNS lookup
imposed by this and similar systems (SPF, SENDER-ID)
create an as-yet unknown and possibly unacceptable
load on the DNS infrastructure. In that context,
adding a TCP lookup on top of an additional DNS lookup
adds quiet a load.
again if the DNS is broken its already WAY WAY broken and indeed you are
correct the MARID specifications add several orders of magnitude to the
problem ..but that said I think the general sense of the DNS Ops and Ext
community has been enough is enough and requirements for additional key
material stored in the DNS itself must prove its case to a very very high
level .
Conclusion its time to recognize the need for pointers for these types of
objects and NAPTR records represents the most flexible and extensible RR we
have for that.
Yes and NAPTR's work ..the support is already in all the DNS reference
models and resolvers.
Regards.
My pleasure.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org sip:57141(_at_)fwd(_dot_)pulver(_dot_)com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<