[dnsop] Comments on draft-ietf-dnsop-key-rollover-requirements

["Olaf M. Kolkman" <[e-mail]>]

Hello Gilles,

I have not looked at this draft for a long, long, time. After hearing
Francis saying that it may be ready for last call it drew my attention
again. Sorry for that.

I have a number of questions and remarks that I have made in-line
below. The overall feeling I have when reading this draft is that it is
a little to restrictive. The draft would be improved if you replace
the "MUST" language (which is not RFC2119 language as far as I can
tell) with language that motivates why certain requirements are
important. An informational document that documents the pitfalls is
more useful than a document that ordains behavior. (Since this takes a
lot of energy I would not do this if there is no general support for
this request from the WG.)

One of the things that could improve the clarity is if you make the
distinction between roll-over and parent-child-key exchange. The second
is part of the first and it seems that you are mostly discussing the
second.


I hope that other WG participants look at this draft as well.

More in-line.



--Olaf





1.  Introduction

   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
   rollover process is necessary for large zones because there are too
   many changes to handle a manual administration.

I think that last sentence should read: 

  Automation of key exchanges between parents and childs is necessary
  for large parent zones because there are too many changes to handle
  manual administration.

This is because the rollover is a local process while the key-exchange
involves two parties.

   Automated rollover is optional and resulting from an agreement
   between the administrator of the parent zone and the administrator of
   the child zone.  Of course, key rollover can also be done manually by
   administrators.

Again this is not so much about key rollover as well as key exchange.

   This document describes the requirements for the design of messages
   of automated key rollover process and focusses on interaction between
   parent and child zone.

s/for the design of messages of/for a protocol to perform the/



2.  The Key Rollover Process

   Key rollover consists in renewing the DNSSEC keys used to sign

s/in/of/

   resource records in a given DNS zone file.  There are two types of
   rollover, ZSK rollovers and KSK rollovers.

   In a ZSK rollover, all changes are local to the zone that renews its
   key: there is no need to contact other zones (e.g., parent zone) to
   propagate the performed changes because a ZSK has no associated DS
   record in the parent zone.

   In a KSK rollover, new DS RR(s) must be created and stored in the
s/In/During/  
   parent zone.  In consequence, the child zone must contact its parent
   zone and must notify it about the KSK change(s).

   Manual key rollover exists and works [3].  The key rollover is built
   from two parts of different nature:
   o  An algorithm that generates new keys and signs the zone file.  It
      could be local to the zone
   o  The interaction between parent and child zones

   One example of manual key rollover is:




Guette & Courtay        Expires February 5, 2005                [Page 3]

Internet-Draft      Automated Rollover Requirements          August 2004


   o  The child zone creates a new KSK
   o  The child zone waits for the creation of the DS RR in its parent
      zone
   o  The child zone deletes the old key.

   In manual rollover, communications are managed by the zone
   administrators and the security of these communications is out of
   scope of DNSSEC.

   Automated key rollover should use a secure communication between
   parent and child zones.  This document concentrates on defining
   interactions between entities present in key rollover process.

You just argued that manual rollover is out of scope of DNSSEC, why
would the automated exchange in scope?  Is the underlying assumption
that you will base the exchange on DNS? If so, that has not yet been
mentioned.


3.  Basic Requirements

   The main constraint to respect during a key rollover is that the
   chain of trust MUST be preserved, even if a resolver retrieves some
   RRs from recursive cache server.  Every RR MUST be verifiable at any
   time, every RRs exchanged during the rollover should be authenticated
   and their integrity should be guaranteed.

A rephrase to express that the chain of trust must be preserver
globally, so to speak:

The main constraint to respect during a keyrollover is that the chain
of trust must be preserved to every validating DNS client no matter if
this client retrieves some of the RRs from a recursive caching
nameserver or from the authoritative servers for the zones involved in
the rollover. Every RR MUST be verifiable at any time, every RRs
exchanged during the rollover should be authenticated and their
integrity should be guaranteed.

(I am not sure if "the main constraint to respect" is proper English.)



4.  Messages authentication and information exchanged

   Every exchanged message MUST be authenticated and the authentication
   tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
   request with verifiable SIG records.

Why? Even if the exchange takes place outside of the DNS like over EPP?

   Once the changes related to a KSK are made in a child zone, this zone
   MUST notify its parent zone in order to create the new DS RR and
   store this DS RR in parent zone file.

This is an example of the use of "MUST" I was referring to above. Why
"MUST" here. When a child chooses not to notify the parent zone if a
change has made in the KSK set nothing breaks as long as the KSK that
the DS points to is not being removed. 


   The parent zone MUST receive all the child keys that needs the
   creation of associated DS RRs in the parent zone.

   Some errors could occur during transmission between child zone and
   parent zone.  Key rollover solution MUST be fault tolerant, i.e.  at
   any time the rollover MUST be in a consistent state and all RRs MUST
   be verifiable, even if an error occurs.  That is to say that it MUST
   remain a valid chain of trust.

I would phrase this differntly, to get rid of those "MUSTs":

Because errors can occur during the transmission of keys between child
and parent the key exchange protocol must be fault tolerant. There
should be mechanisms to allow the child zone to verify that the parent
has received the appropriate key material and allow for timely
retransmition of the key data.



5.  Emergency Rollover

   A key of a zone might be compromised and this key MUST be changed as
   soon as possible.  

Why? I think we all agree this is needed but if you say "MUST" I think
you should motivated.


   part of DNS tree having this zone as apex can become unverifiable,
   but the break of the chain of trust is necessary if we want to no one
   can use the compromised key to spoof DNS data.

The sentence doesn't parse (s/to no one/that no one/ ??)

   In case of emergency rollover, the administrators of parent and child
   zones should create new key(s) and DS RR(s) as fast as possible in
   order to reduce the time the chain of trust is broken.


Maybe expand the reasoning a bit, include some timing issues.

If at t=0 the key is compromised the key will be vulnerable until the
DS RRSIGs expiration value at t=0 (or of those RRSIGs over DS created
after t=0). During that time the DS with a valid RRSIG can be inserted
by an attacker. An automated key exchange mechanism should be able to
notify the parent not to create new RRSIGs over the existing DS
RR. After this notification took place parent and child have until the
signature expiration time of the "last RRSIG generated over the DS RR
pointing to the compromised key" to perform a key exchange. This key
exchange should not be based on keys that depend on the compromised
key. In practice this may result in having to bootstrap the trust
relation.


6.  Other Resource Record concerned by automatic rollover


This section has EPP written all over it :-) Actually Scott has incorperated
text on DNSSEC key exchange in one of the epp drafts.


---end---




.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html