Subject: One Interaction KEY exchange

From: Olaf Kolkman <[email-masked]>
Date: Fri, 06 Apr 2001 15:07:45 +0200

Ref: draft-ietf-dnsop-parent-sig-00.txt

Using the ideas from draft-ietf-dnsext-parent-stores-zone-keys-00.txt
this is an alternative to the key exchange mechanism described in
section 4 of that draft (which is the same as in
draft-ietf-dnsop-parent-sig-00.txt)

I think one can restrict the parent-child interaction even more. I get
to only 1 child parent interaction and an optional parent child
interaction. During the rollover the parent only needs to sign keys
once instead of twice.

Consider the following

1. To initiate a key rollover the child replaces the KEYold by the
KEYnew, signs KEYnew and the rest of the zone using the old and new KEY.

Then the child signals the parent to initiate the rollover.

2. The parent fetches the new key with the double signature and verifies
the SIG made with the old KEY with the old child KEY that the parent
is authoritative for. If the SIG is correct the Parent publishes the
new KEY with parental signature.

Since all child zone data is already signed with the new key that
data is also validated against the now signed KEYnew.

3. Once the child notices (or receives the optional signal by the parent)
that KEYnew has been signed the child can remove the SIG made with
KEYold. This is not a resigning exercise. A simple 'grep -v' will do.

To put this in a hopefully readable table:     
__________________________________________________
KEYold is  the child's old key RR
KEYnew is  the child's new key RR
SIGparent(RR) is the parental signature over RR
SIGkeyold(RR) is the child  signature over RR using keyold
SIGkeyold(RR) is the child  signature over RR using keynew
(At all times the child has signed the complete zone with the same keys 
as it signed the KEY record with.)
_______________________________________________________________________________
Time               Parent state              Child state         Comment
_______________________________________________________________________________

0                  KEYold                 KEYold            Before key rollover
                   SIGparent(KEYold)      SIGkeyold(KEYold)
            
1                  KEYold                 KEYnew             Shortly before 
                   SIGparent(KEYold)      SIGkeyold(KEYnew)  rollover
                                          SIGkeynew(KEYnew)  This works 
                                                             because parent 
                                                             is authoritative.

2a   SIGNAL to parent parent fetches KEYnew with the two sigs. It can verify
     SIGkeyold(KEYnew) against the data it holds itself. then replaces KEYold 
     by KEYnew and signs
  
2b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeyold(KEYnew)
                                           SIGkeynew(KEYnew)

3a  SIGNAL from parent to child. Child checks signature over KEYnew and 
    knows it can dispose of SIGkeyold(KEYnew)

3b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeynew(KEYnew)

_______________________________________________________________________________

In the mentioned draft the child always publishes one KEY RR in its
KEY RRset that is signed by the parent. This is not the case in this
model still all arguments in paragraph 7 apply.

Paragraph 7:

"  There are two reasons to have of the child's zone KEY not only at the
   parent but also in the child's own zonefile: 
	1. to facilitate a key rollover  
	2. to prevent local lookups for local information to suffer 
           from possible loss of access to its outside parent

   To cope with 1, secure aware resolvers MUST be aware that during a
   key-rollover there may be a conflict, and that in that case the
   parent always holds the active KEY set.  To cope with 2, the local
   resolver/caching forwarder should be pre-configured with the zone-KEY
   and thus looks at its own zone as were it a secure entry-point.  For
   both things to work, the zone-KEY set must be selfsigned in the child
   zonefile.
"

As far as I can tell this scheme is still immune for fake signals
since the Parent will only update if it finds another key at the child
then the key in it's own zone. Besides, a spoofed new keyset will not
validate since it is not signed with the verifiable SIG made with the
old key.

To cope with point 2 from par 7 the zone administrator should configure
the local resolvers and forwarding caches with the KEYnew somewhere
between step 1. and step 2a. in the table

I welcome your merciless responses :-)

- --Olaf

- -----------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC 
     -----------       |      ---------------	   
  RIPE NCC             |  Phone:   +31 20 535 4444
  Singel 258           |  Fax:     +31 20 535 4445
  1016 AB Amsterdam    |  http://www.ripe.net
  The Netherlands      |  [email-masked]

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 10 Apr 2001 15:37:41 +0200

[Quoting Olaf Kolkman, on Apr  6, 15:07, in "One Interaction KEY  ..."]
> Ref: draft-ietf-dnsop-parent-sig-00.txt

 <Single parental action key-rollover scheme>

Let me first say, that I like this idea a lot: it further reduces
the amount of action that a TLD needs to do for key-rollovers of
its children.

Next, I'd like to refrase the basic difference to make sure
I understand it (please jump on it, if this is wrong):

- instead of having a double key in the zone key RRset during
  the transition, there is a double set of SIG RRs at the child.

Let's see how this affects the various parties:

1. The parent (say, a TLD):
   Instead of two (identical) key-RRset update actions, only
   one is needed. This is an advantage.
2. The child:
   Instead of key-addition+double-key+key-removal, the child goes
   through key-change+double-sigs+sigs-removel. Not much of a
   change of work.
3. The resolver:
   As, from security needs, the resolver must already know whether
   to expect SIG-RRs before entering a child's zone, it is probably
   no extra work to know which SIGs to expect if it finds multiple
   SIGs. So, not much of a change of work here as well.

So, it looks like an advantage only.

One thing, however, bothers me a little bit:
- at all times, and thus also during the transition, in the scheme
  used in draft-ietf-dnsop-parent-sig-00.txt the "real" or "valid"
  or "validated" zone-KEY-RR is present in both the parent and the
  child zone. However, the RRsets may differ during the transition.
- in the proposed scheme, the childs zone does not hold the "real"
  zone KEY RR during the transition, it holds the upcoming, thus
  no (yet) valid one instead.

But, I must admit, that in both cases there is an anomaly....

Perhaps we need to rethink, why the zone-KEY-RR (and RRset) was
at all present in the childs zonefile, if we already have decided
that the parents zonefile is (more) authorative for it: the only
reason was to facilitate easy KEY-update by the parent:
 - child updates zone-KEY-RRset, signs with old-KEY, signals parent
 - parent gets RRset, checks against KEY it holds and updates.
This scheme is used in both draft-ietf-dnsop-parent-sig-00.txt
and Olaf's proposal.

What now comes to mind is, that if we take Olaf's proposal a
little bit further, we could get rid of the anomaly as well:
-  Why not remove the zone-KEY-RRset from the childs zone file
   alltogether. If we already accept that the parent is (more)
   authorative, and the set may be wrong at the child, this
   looks quite natural to me.
-  The only thing that must change is how the parent gets a
   new zone-KEY at key-rollover time. This means that the
   "trigger" that was proposed earlier, now changes into
   a "new-KEY-message".

Security considerations:
The main thing is, that the parent never ever signs the
wrong zone-KEY.
Two possibilities:
1. The old zone-KEY is still OK.
   The child could send an e-mail form, or fill out a web-form,
   or send a FAX or whatever, to trigger the parent and handover
   a new KEY at the same time. Of course, anyone can do that, but
   only the holder of the private part of the old-KEY could sign
   such a request with the old-KEY. So, if the parent just requires
   this, it is simple and sufficient.
2. The old zone-KEY is not OK anymore.
   Now we have a problem, but we have this problem in all cases.

Regards,
-- Ted.