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


To: dnssec@cafax.se
Cc: lewis@tislabs.com
From: Edward Lewis <lewis@tislabs.com>
Date: Tue, 4 Dec 2001 13:44:30 -0500
Sender: owner-dnssec@cafax.se
Subject: Where are we (metaphorically speaking)?

I want to start a collection of the threads being pursued in the area, so
we can  judge importance, not just progress.  IMHO, securing the tree is
the first thing we need, although support for application keys is a big
driver.  The following is a list of issues and catagories.  The ordering of
the categories is how I see the importance of each.  The relative placement
of the issues withing the category is only somewhat sorted by importance,
e.g., in "other" the issues are listed as they came to mind.

Are any issues missing or mis-sorted?

1) Securing the tree

Issue #1

Indicating parent validation of child.  This is RFC2535's sig@child vs. DS
RR, and at one time sig@parent.  DS RR drafts are being produced, and
prototype code is being debugged.

Issue #2

Parent-Child key interface.  A couple of folks have been talking about
this.  One of the debates is whether keys (or references thereto) travel
in-DNS-band or out-of-DNS-band.

Issue #3

Adoption approaches.  This refers to unsigned records and "opt-in."
Haven't heard a lot on this in recent months.

2) Support for applications

Issue #4

Application/Non-DNS public key distribution.  We know that KEY is
insufficient for at least SSH.  APPKEY is an improvement, but is it
sufficient?  IPsec is emerging as a protocol that can benefit from DNS
security enhancements.  An effort has begun to identify key distribution
needs of other protocols to determine if and how DNS can help (basically by
answering whether APPKEY is sufficient).

Issue #5

Interpretation of DNS results.  Basically a need to state what DNS
validation means, and what the fallbacks are when answer fail to validate.
Not all applications will want hard failures, some will.  What helps here
is an annotated validator (kind of like dig for DNSSEC).  Some first-ste
implementations of this exist.

3) Operational considerations

Issue #6

Distribution of trusted keys to resolvers.  How are the configured trusted
keys changed in resolvers throughout a realm?  Olaf's draft.

Issue #7

Root zone key management issues.  (Root server engineers.)

4) Other

Issue #8

Updating crypto-specifications.   I.e., change from HMAC-MD5 to HMAC-SHA-1,
updates to DSA and Diffie Hellman.

Issue #9

Maturation of TKEY and SIG(0).  One draft has appeared in this area.

Issue #10

DNSSEC interactions with Dynamic Update.  Resigning zone data that hasn't
been refreshed versus dropping data with expired signatures.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Opinions expressed are property of my evil twin, not my employer.



Home | Date list | Subject list