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
