Subject: Rollover pointed questions.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 5 Oct 2005 10:09:02 +0200

Dear Colleagues,

We would like to get some forward motion on key management.

With reference to http://ops.ietf.org/lists/namedroppers/namedroppers. 
2005/msg01280.html.
I am opening a new thread and ask  variations of the pointed  
questions that Paul suggested.

For the purpose of this mail there are two angles on the key- 
management issue:
   - Initial distribution of trust-anchors
   - Maintenance of existing trust-anchors, or automatic rollovers.

= Can DNSSEC be deployed without key management protocols?
    * Is either angle of the  key-management issue a tools issue only  
or do we
      need to standardize the behavior on both sides of the wire.
   * Do we need one unique solution?

= Is the trustupdate-timers draft [1] a proposal that provides  
sufficient basis for a rollover
      protocol
    * What essential parts seem to be missing, if any.
        * The requirements for this work have never been spelled out.  
Do you requirements that
           are not being addressed in the draft?
    * Are there competing proposals that provide better solutions?
        * Either because they have no IPR claims or have non- 
restrictive licensing [*]
        * They are better engineered
    * Is [2] an alternative that needs to be kept alive? If so do we  
have a volunteer editor?

=  Should the work on initial distribution of trust anchors be  
continued in this group.
    * Are the requirements for this work clear enough? ... huh..  
which requirements :-)
    * Are the proposals available now (in parts of [2] and in [3])  
sufficient basis for continued work?
    * Is there sufficient commitment to do this work in DNSEXT?
       + Should we spawn off a BOF/WG in order to do this work?

If there is not further discussion we will last call the trust update  
timers draft (shortly after the Vancouver IETF) and propose that no  
further work in DNSEXT is done on the initial distribution of trust  
anchors.

- - --Olaf Kolkman
    DNSEXT co chair.

[1] http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate- 
timers/

[2] http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate- 
threshold/draft-ietf-dnsext-trustupdate-threshold-00.txt

[3] http://ietfreport.isoc.org/idref/draft-laurie-dnssec-key- 
distribution/

  [*] The IPR claim itself is not something we want to discuss.  We  
want to avoid rat holing on licensing discussions so please carefully  
state your arguments and state them only once.

- -----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

--
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/>

---

From: Mike StJohns <[email-masked]>
Date: Wed, 05 Oct 2005 13:47:32 -0400

At 04:09 AM 10/5/2005, Olaf M. Kolkman wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>Dear Colleagues,
>
>For the purpose of this mail there are two angles on the key- management 
>issue:

Yes, but....  For keys that aren't trust anchors, the management protocols 
exist already.  We can deploy a system where we don't have a way of rolling 
a trust anchor, but a compromise of the anchor could have some interesting 
consequences if DNSSEC became relied upon.

>      need to standardize the behavior on both sides of the wire.

I don't quite understand this question, but let me try to parse it.

The possible engineering approaches here basically resolve to one of two 
paths - either we do this inband with DNS or we do it out of band with 
another protocol.  In some ways that may be a more appropriate 
approach.  An out-of-band (from DNS) approach isn't part of either proposal.

  If we do it with DNS we have some limitations.  Since DNSSEC is a one-way 
data protocol (e.g.  the client can't interact directly with the publisher 
of the data (publisher != server)) what needs to be standardized is the 
behavior of the client to the receipt of data.  Think of it this way - what 
would you do if you approached a stop light in the US and the light turned 
from green to yellow then back to green?  You can't send a query back to 
the stop light asking what it meant, you have to understand the meaning 
from what you saw. So with DNSSEC the client can only take actions based on 
what it sees.  So its more of a client behavior problem than anything else.

>   * Do we need one unique solution?

This question also has at least one branch which further complicates the 
engineering.  E.g.  Do we need one unique solution at any given trust 
point?  If so, how does the client determine which applies to which trust 
point?

I think the answer to the question is probably yes.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 06 Oct 2005 07:17:08 +0100

Mike StJohns wrote:
> Yes, but....  For keys that aren't trust anchors, the management 
> protocols exist already.  We can deploy a system where we don't have a 
> way of rolling a trust anchor, but a compromise of the anchor could have 
> some interesting consequences if DNSSEC became relied upon.
> 

However,  http://ietfreport.isoc.org/idref/draft-laurie-dnssec-key- 
distribution/ is out-of-band and could just as easily be used for 
rollover as it is for initial distribution.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff