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

[Gilles Guette <[e-mail]>]

Olaf M. Kolkman wrote:

>
>
>Hello Gilles,
>
>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.  

You're right, the "MUST" language will be corrected in the
next version


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

Maybe the terms has to be defined more precisly:

key rollover: local process to change key material in a zone file
key exchange: transmission of the key material between parent
and child zone

And we need a term for the entire process keyrollover + key
exchange (+ DS creation)

Any precision or suggestion ?


>2.  The Key Rollover Process
>
>   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:
>
>   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,

Oops, I made a mistake, the right sentence is:
... and the security of communications during a manual rollover is out 
of scope of this
document.

>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.)

It is an open question :)

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

This part was an open question of the first version of the draft.

Do we need other mechanisms than DNSSEC one's to provide security?

A mechanism is needed to provide this security and there is two
solutions, either this mechanism is DNSSEC or not. We think that
securing the exchanged messages with DNSSEC is the more
appropriate and allow to be independant from other protocol.


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

Ok, I change that.

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

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

I will add something describing consequences of a compromised key in
DNSSEC and explaining the motivation of the key change as
soon as possible.




-- 
           \|||/
           (@ @)
    ---ooo0-(_)-0ooo---
          --Gilles--

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