Subject: DNSEXT Minutes @ IETF-63

From: "Jim Cassell" <[email-masked]>
Date: Wed, 14 Sep 2005 08:05:09 -0400

At the DNSEXT meeting in Paris I was "volunteered" to review the two 
draft proposals that deal with updating trust anchors.  If the 
intention was for me to somehow define which draft is the "best", then 
I have failed.  I do not feel qualified to make that determination.  
But, perhaps this review will at least stimulate some discussion on the 
subject, which will eventually lead to a clearer way ahead.

To differentiate between them I am going to call the Mike St Johns 
draft the "timers" draft; and the Ihren, Kolkman, Manning draft the
"threshold" draft.
First, I've written a very short overview of each draft, then listed 
the major differences, then a short conclusion.

Automated Updates of DNSSEC Trust Anchors - 
draft-ietf-dnsext-trustupdate-timers-00 (Timers Draft):

Provides a means for automated, authenticated, and authorized updating 
of trust anchors.  Protects against single key compromise.  Requires 
changes to resolver management behavior, and the addition of a single 
bit flag to the DNSKEY record.  Existing trust anchors are used to 
authenticate new trust anchors at the same point in the DNS hierarchy.  
Protection against key compromise is accomplished via a revocation bit.  
When set to "1" in the key, this bit signifies that it must not be used 
as a trust anchor.  Further protection against compromise is provided 
by the implementation of both "add" and "remove" hold-down timers.

An In-Band Rollover Mechanism and an Out-of-Band Priming Method for 
DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-threshold-00 
(Threshold
Draft):

Assumes that keys with the SEP flag set are used as key signing keys.
Provides an in-DNS mechanism to track key rollovers and modify the 
configured trust anchors.  The key update algorithm can be expressed as 
M of N; where N represents the total number of SEP keys a zone owner 
publishes, and M represents the minimum number of those keys needed to 
verify a key rollover (the number M is chosen by the resolver
administrator).

Also provides an out-of-band method to establish the validity of trust 
anchors for initial configuration (or priming).  This method can also 
be used to recover from a trust anchor "stale" state.

Differences:

Perhaps my previous relative lack of familiarity with DNSSEC in 
general, and specifically with these drafts, is preventing me from 
discerning all the various nuances involved.  But, to me at least, it 
seems that there is a lot in similarity between them.  I don't mean to 
over-simplify, as certainly there are many differences between them, 
but the major differences seem to come down to:

1.      The Timers draft includes a revocation mechanism as a security
measure to protect against a key being compromised.  The Threshold 
draft intentionally does not include a revocation mechanism based on 
the fact that "any reasonable trust anchor rollover policy (in 
validating resolvers) will require more than one RRSIG to validate", 
and that zone admins can store private keys separately "thereby 
decreasing the likelihood of simultaneous compromise".

2.      The Threshold draft includes the concept of a "priming key" that can
be used to establish                the validity of trust anchors for
initial configuration or when trust anchor become stale.  The Timers 
draft states that it "does not discuss the general problem of the 
initial configuration of trust anchors for the resolver".

Conclusion:

There was some discussion at the Paris meeting about the possibility of 
allowing both proposals to be implemented and developing some kind of 
signaling mechanism to identify which method is being used.  Of course 
others may disagree, but I think that while this kind of arrangement 
makes sense to try to reconcile two methodologies that are already 
deployed, I don't think it is the optimal way to design/implement a new
feature.
Although I do not feel qualified to choose the "best" draft, I do think 
a single choice should be made.

-Jim

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>