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: Miek Gieben <[email-masked]>
Date: Wed, 18 Jun 2003 16:22:11 +0200

[On 18 Jun, @15:20, Olivier wrote in "Comment on draft-stjohns-secur ..."]
> some comments on your draft.

this triggered me to also comment :)

In the draft the notify is signed with the private key from 
the child's zone. The experiment currently running in nl (SECREG)
also uses the child's key as a mechanism to authenticate child
zone administrators. But this has severe impact on how a registry
operates. In SECREG the holder of the private key of a domain is
called the sec-c, the security contact.

This draft describes ways for the sec-c to directly contact the
registry, thereby bypassing the registrar. Also if something
goes wrong with the private key of the sec-c, the registry is
involved since it allowed access with that key. I'm currently
documenting this kind of stuff for SIDN.

A registry could continue to use the current registrant <-> registrar 
<-> registry model. This would mean that it cannot use the mechanism
described in this draft. A registrar would not be in the possession
of the private key of a (child) domain.

If a registry want to use such a mechanism a lot of other things also have to be
decided of which the most important one is: are we still going to use
registrars?

>    - parent responds to the child by a NOTIFY Response.

Why is this different (expect for the inband NOTIFY mesg) than sending
an encrypted email with the NOTIFY in it. Which can be handled by the
registrar, just like the normal DNS operations are handled today?

Maybe this email is a bit cryptic, but what I want to say boils down to this.
Be very carefull when using the key information in DNSSEC. It has implication
on almost every aspect of DNS, esp. the registration side of it.

grtz  Miek

--
NLnet Labs
:wq!

---

From: Olivier Courtay <[email-masked]>
Date: Wed, 18 Jun 2003 17:54:24 +0200

>this triggered me to also comment :)
Hello Miek,

>of the private key of a (child) domain.
Yes, in our model, the private key isn't needed, the validation of data 
is done using DNSsec validation (chain of trust).
New keyset are generated automaticaly but not immediately integrated on 
the zone (like a CA with Certificate request).

I'am right with you that relations between entity are very important.

For encrypted email,  how authenticated the peer ? you need X509 
certificate, Pre-Shared Key or use the private DNSsec Key?
If you decide to use the private key, thus the sec-c is connected to 
Internet, it's not good.....

Our proposed scheme (read with a fixed font):

+----------------------+
|  Parent sec-c        |-----------    9 off-line   -----------------+
+----------------------+                                             |
    /\                                                               |
     |                                                               |
     | (off-line)                                                    |
     |                       7                                      \/
     L__  8 __   Key Roll Over Service <---------  4 -------   Parent Server
                           /\                                    /\
                           |                                      |
                           |                                      |
                           L---- -----------  5  and 6 -------+   3
                                                              |   |
                                                              |   |
+----------------------+                                     \/   |
 |   Child sec-c        |--------------- 2 -------------> Child Server
+----------------------+                (off-line)
       1

1) the Child sec-c sign his zone.
2) the zone's file is transfered off-line to the child server.
3) the child server see that there is glue change and send a NOTIFY (not 
crypted and with the SOA) to the parent server.
4) the parent server forward the NOTIFY to the Key Roll Over Service (we 
have begin to implemented this) .
5 and 6) the Key Roll Over Service collect needed informations (child 
KEY RRset).
7) the Key Roll Over Service validate the data using DNSsec chain of 
trust (with the DNSsecToolKit available at www.dnnsec.net ;-) )
8) the keyset is generated and available to the parent sec-c by an 
off-line transfert.
9) when he wants the parent sec-c sign the zone file........

>registrar, just like the normal DNS operations are handled today?
The result is the same but private-key isn't used and sec-c stay off-line.
All work can be done automaticaly except when informations are 
transfered off-line (human validation can be done here).
If you want a total automatization, you can replace off-line mechanism 
by on-line and automated mechanism (At your own risk).

Gilles GUETTE
Ph.D student
Armor Project

---

From: Miek Gieben <[email-masked]>
Date: Wed, 18 Jun 2003 20:33:10 +0200

[On 18 Jun, @17:54, Olivier wrote in "Re: Comment on draft-stjohns-s ..."]
> >this triggered me to also comment :)

SNIP

> certificate, Pre-Shared Key or use the private DNSsec Key?

yes, another mechanism is needed, but current registries already have
that mechanism. The make and give out password to their registrars.
(that some still use plain-text and the registrars are sloppy with their
password is one more reason to _not_ use the DNS keys for this kind of
work)

> 9) when he wants the parent sec-c sign the zone file........

I'm fully aware that this works, i've implemented it for SECREG and it is
working for more than six months now.

> by on-line and automated mechanism (At your own risk).

The issue i'm referring to is not if these methods for updating
keys/DS/NS/whatever work, 'cause they _do_ work. The issue here is how
people see the future of registries in a DNSSEC world. If you give the sec-c
rights to access the registry _directly_ you almost have done away with
registrars...

grtz Miek

---

From: Mike StJohns <[email-masked]>
Date: Wed, 18 Jun 2003 16:47:47 -0400

Hi Olivier...

Some problems with your approach:

>    - child send a NOTIFY (including only his SOA record),

Won't work - see below... child needs to send a notify which points at 
either the KEY or NS records.

>    - parent checks if DS is present on his zone for the child zone,

This should come after the NOTIFY is received and the parent should respond 
to the NOTIFY yea/nay based on whether a DS is present... cheap and fast 
test that happens without requiring the parent to query the child.

> necessarily on the server),

But the private key is available when the child signs the zone, its not a 
stretch that the NOTIFY can be signed at that time.

>    - the NOTIFY message contains the serial number of the child zone, so 
> the parent can deduce that the child zone has changed or not,

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.

>    - parent has checked the child zone configuration status and the chain 
> of trust is validated.

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

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

>problem too). In this case, the parent only has to forward the NOTIFY to 

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.

2) Selfishness Principle:  In general, its a good idea to place the 
responsibility for an action on the party who benefits most from the action.

In this case, the child is the beneficiary and anything it can do to make 
it easier for the parent to update the data pointing to the child improves 
the chances the data will actually get updated.  If the child has to depend 
on the parent to take notice of the NOTIFY, suck in the records, notice the 
changes, derive the new data, etc... it might not get done.  I refer you to 
the general tone of the opt-in discussion.

3)  Load Balancing Principle: In general, when you have a choice between 
having one entity responsible for many actions or having many entities 
responsible for a few actions, the latter is preferable.

This is a corollary to the selfishness principle in that it generally makes 
sense for clients to track their own state, especially if you can by doing 
so make the server stateless.  E.g. keeping persistent state for a few 
clients is OK, but trying to keep persistent state for 10s of 1000s of 
clients who have their own notion of the world can be daunting and require 
a lot of state resynchronization.

Basically, I'd rather not have to have the parent zone track anything more 
than whether or not an accepted change is still requiring signature and 
publishing.

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

Later, Mike

---

From: Gilles Guette <[email-masked]>
Date: Thu, 19 Jun 2003 14:45:30 +0200

> Mike StJohns wrote:

SNIP

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

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

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

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