Re: One Interaction KEY exchange

[[e-mail] (Ted Lindgreen)]

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