[dnssec-deployment] Discussion document for 14 July 2004 meeting

[Mike StJohns]

Hi Amy, et al,

I got about 1 sentence into this and ran into a problem.

>The goal for global DNSSEC deployment can be stated as follows:
>"Every lookup request requires and receives only DNSSEC-validated answers, 
>and the process works efficiently."

*yipe*  Suggest instead:

"Every lookup request that asks for DNSSEC-validated answers gets them, and 
the process works efficiently and without adverse impact on the DNS system 
as a whole."

My opinion is that the goal is not universal queries, but universal 
availability of the responses.  We need to spend enough time today getting 
the goal correct.

Change "cycles" to "processes".  Change "C" to "P". Change "CC" to 
"C".    "cycle" implies periodicity, and exact repetition.  Lookups are 
anything but repetitious especially when viewed from the server.   Process 
is "2b : a series of actions or operations conducing to an end; especially 
: a continuous operation or treatment especially in manufacture"

In Figure 1 - tag the "Zone Server" with a "master" tag.  Tag the secondary 
with a "zone server" tag.

The lookup process assumes an intermediate caching server.  The protocol 
doesn't.  We need to capture both.

The "Registrant" process is too heavily registry/registrar centric.  The 
average zone (e.g. most anything except .COM/.NET) combines the two 
roles.   Either this needs explanation, or we need to split these processes 
out.

The trust anchor configuration process is different from the trust anchor 
update process.  The former is a decision to trust a particular key for the 
purposes of DNSSEC and the secondary decision (if this is done at a caching 
server) as to treat non validated data as bad at the caching server.  The 
latter is a key management process to change/add/delete one trusted key at 
a specific trust point.  The policy item here is whether or not you allow 
the key management process to twiddle the key.

zone signing/setup needs to be broken out into two items.  The first to 
cover the initial deployment, the second to cover the "re-signing" as 
signatures expire.    This is different than changing out the keys.  The 
keys have life times, the signatures have validity periods which notionally 
are sub ranges of the key lifetime.

4.1.13 shared key.  This is important, but not to this document.  This is 
an intrazone issued (e.g. updating tsig keys).  Not sure it should be 
here.  If we retain it, needs to be moved to a section that's not dealing 
with DNSSEC.

The process for zone signing key replacement is the same for either 
graceful or emergency roll over given the current protocols - we don't need 
different processes identified in the document.  This is not the case for 
the KSKs as they require update of non-zone data (e.g. at the parent, at 
the resolver if a trust anchor).  The keys are embedded in the DNS and will 
be updated when DNS caching timers expire, etc.



At 04:54 PM 7/13/2004, Amy Friedlander wrote:
>Good afternoon.  Please find attached the working document that reflects 
>the discussions that have taken place around formulating the roadmap 
>document. Please consider this documentation of work in progress and 
>please do not circulate it beyond the group.  That said, and recognizing 
>that it is a substantial document to think through, it would be helpful if 
>you might give some thought to the following:
>
>(1)     What works and what's missing from a technical perspective?
>(2)     How would we tailor the message to different audiences? And who 
>are these audiences?
>(3)     Is the list of issues (section 5) sufficient? What's missing? Does 
>the proposed the format for the responses work? Namely, -a cogent 
>expansion of the term that frames the question; history; current status, 
>relation to other issues; next steps; name the major protagonists.
>
>I'll be taking notes. . . .
>
>Amy
>
>
>#############################################################
>This message is sent to you because you are subscribed to
>   the mailing list <dnssec-deployment at shinkuro.com>.
>To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
>To switch to the DIGEST mode, E-mail to 
><dnssec-deployment-digest at shinkuro.com>
>To switch to the INDEX mode, E-mail to <dnssec-deployment-index at shinkuro.com>
>Send administrative queries to  <dnssec-deployment-request at shinkuro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20040714/8a263e22/attachment.html