Subject: Comment on draft-stjohns-secure-notify-00

From: Olivier Courtay <[email-masked]>
Date: Wed, 18 Jun 2003 15:20:44 +0200

Hi,

We are also currently working on the Key RollOver subject and we have 
some comments on your draft.

you propose three methods : Automatic, Manual and Parent Pull.
Our solution is very similar to your Parent Pull method.
In our opinion we think that Parent Pull is a better choice because with 
this method SIG(0) is not needed anymore.

For example for the DS records update case, we have the following scenario:
    - child send a NOTIFY (including only his SOA record),
    - parent receives this NOTIFY,
    - parent retrieves needed information from his child,
    - parent checks if DS is present on his zone for the child zone,
    - parent checks if a KEY in the KEY RRset is validated by a DS,
    - parent validates the KEY RRSet with this KEY,
        -> Now, the parent can trust all KEY in the KEY RRset and can 
build the right keyset,
    - parent responds to the child by a NOTIFY Response.

There are three advantages with this method:
    - SIG(0) is not necessary (therefore the private key is not 
necessarily on the server),
    - the NOTIFY message contains the serial number of the child zone, 
so the parent can deduce that the child zone has changed or not,
    - parent has checked the child zone configuration status and the 
chain of trust is validated.

For NS record update, Notify and changes validation are used on the same 
manner.
For NS record update, two solutions: if the private key is present on 
the server, it can immediately sign the zone with new glue (Automatic 
case) or put in a file the new glue for this child (in the same manner 
than a keyset file) which will take effect after the next zone signature 
(Manual case).

In the parent Pull method, the parent has more work to do, but this work 
could be delegated to an other service (to avoid Deny Of Service attack 
problem too). In this case, the parent only has to forward the NOTIFY to 
this other service.

The problem is that these methods can not be used for the initialization 
of the chain of trust, i.e. the first time a zone is secured.
At the beginning of the DNS delegation, the parent can not identify his 
child because no DS exists.

We work on the automatization of DNSsec administration and will provide 
some results in a near future.

Regards,

--
Olivier COURTAY
Research engineer
IDsA Project (www.idsa.prd.fr)
ENST Bretagne( www.enst-bretagne.fr)

Gilles GUETTE
Ph.D student
Armor Project
Irisa/Inria (www.irisa.fr)

--
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: Gilles Guette <[email-masked]>
Date: Thu, 19 Jun 2003 14:45:30 +0200

> Mike StJohns wrote:
> Hi Olivier... 
> 
> Some problems with your approach:
> 
> At 09:20 6/18/2003, Olivier Courtay wrote:
> 
> 
> Won't work - see below... child needs to send a notify which points at 
> either the KEY or NS records.

SNIP

> This goes back to my "won't work" comment.  The parent zone does not and 
> should not contain a copy of the child SOA.  Without this, the parent 
> doesn't have the old serial number so it can't figure out if it needs to 
> do a retrieval.  There are also a *lot* of changes in the child zone 
> that the parent doesn't and shouldn't care about  - the parent ONLY 
> cares about changes to glue NS and the KEY records pointed to by the DS 
> records it holds.  However, the serial number MUST change with ANY 
> change in the zone contents.

The use of serial number was just an optimization. It wasn't a problem 
if you don't use serial number. Moreover if you want to use serial 
number verification, parent don't care about every serial number 
changes. It do it ONLY if it receives a NOTIFY.

> How is this different from the entity who holds the KSK or ZSK sending a 
> NOTIFY which chains to the DS held by the parent for the child zone?  
> And as above, the parent shouldn't care about the child zone 
> configuration, only about the glue it holds that points to the child zone.
> 
>> For NS record update, Notify and changes validation are used on the 
>> same manner.
>> than a keyset file) which will take effect after the next zone 
>> signature (Manual case).
> 
> 
> Per  RFC2535 and its replacement - the NS records at the parent aren't 
> signed by the parent (emphasis mine):
> 
> 
>    "Every name in a secured zone will have associated
> with it at least
>    one SIG resource record for each resource type under that
> name EXCEPT
>    for glue address RRs and delegation point NS RRs.
> "

We know this text but tell my if I'm wrong, in the child zone NS RR are 
signed. This NS RR and SIG(RR) can be retrieve by parent zone in order 
to verify their validity. After validation NS RR (glue) are included in 
the parent zone file, without SIG(NS).

This method avoid the use of SIG(0) that is not, in my opinion, a simple 
  process.

> One day I'm going two write a "how to design a protocol" and three 
> things that will go in it are the "Complexity Principle", the 
> "Selfishness Principle" and the "Load Balancing" principle.
> 
> 1) Complexity Principle:  When facing two separate choices to accomplish 
> the same thing in a protocol, generally the simpler choice is the 
> correct choice.   
> 
> Having to have yet another service/server act as a proxy to the parent 
> to do this is an order of magnitude increase in complexity and probably 
> not a good idea unless there's a substantial benefit.

Using such a service is to protect against eventual DoS attack and not 
increase the burden on the the parent name server but this is not the 
heart of our method, we can  totally include this service in parent server.

SNIP

>> The problem is that these methods can not be used for the 
>> initialization of the chain of trust, i.e. the first time a zone is 
>> secured.
>> At the beginning of the DNS delegation, the parent can not identify 
>> his child because no DS exists.
> 
> 
> Yup - this is the general enrollment problem.  Not being considered 
> here.  I assume there are some manual interactions that need to take 
> place to do the original delegation, but that once that's done I want 
> the key management system (e.g. the DNSSEC system) to do the right thing 
> as keys change.

OK

> Later, Mike

--
Olivier COURTAY
Research engineer
IDsA Project (www.idsa.prd.fr <http://www.idsa.prd.fr/>)
ENST Bretagne( www.enst-bretagne.fr <http://www.enst-bretagne.fr/>)

Gilles GUETTE
Ph.D student
Armor Project
Irisa/Inria (www.irisa.fr <http://www.irisa.fr/>)