ietf-mailsig
[Top] [All Lists]

Re: Anonymous signed mail

2004-08-30 14:59:46
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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<Prev in Thread] Current Thread [Next in Thread>