Subject: Re: WGLC on rollover-requirements and trustudpate-timers

From: Thierry Moreau <[email-masked]>
Date: Mon, 02 Oct 2006 10:30:05 -0400

Dear wg participants:

Since DNSEXT participants are invited by Olaf to discuss the TAK
rollover requirements/protocol documents, and since Scott Rose message
casts a doubt on intellectual property encumbrance of
draft-ietf-dnsext-trustupdate-timers-04, I provide the following
information to the namedroppers mailing list.

(A) There may be a connection between the fairly generic claim 20 in US
patent 5,761,306 ("Key replacement in a public key cryptosystem",
assigned to Visa International) and the DNS zone administration
procedures suggested in section 5 in
draft-ietf-dnsext-trustupdate-timers, in which a distinction is made
between an "active" and a "standby" DNSKEY RR, and only the "active" one
is used to sign the DNSKEY RRset at the zone apex.

(B) The above US patent is expired due to failure of maintenance payment
to the USPTO. The reference is
http://www.uspto.gov/web/offices/com/sol/og/2002/week31/patexpi.htm.

(C) The above US patent application seems to have led to the
international PCT application PCT/US1997/002984.

(D) I am not aware of national phase entries in the above international
PCT application (a search in the Canadian Intellectual Property Office
on-line database gave an empty result).

Given the obvious IETF inefficiencies in handling IPR issues, compounded
by the wording of IPR un-encumbrance requirement in the TAK requirement
document, I abstain from further comments on this issue.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 9 Oct 2006 14:35:41 +0200

Colleagues,

This is a reminder. The WGLC closes in about 2 days; we have not met  
quorum yet.

If you plan to review the document but need a few more days, please  
let us know. I'd hate if we would need to declare bankruptcy at this  
stage because of lack of review by the working group.

--Olaf

(Top-Posting)

On 25Sep 2006, at 10:00 PM, Olaf M. Kolkman wrote:

>
>
> Dear Colleagues,
>
>
> This message starts the working group last call for two documents
>
>           draft-ietf-dnsext-rollover-requirements-03
>      Requirements related to DNSSEC Trust Anchor Rollover
>
>
>             draft-ietf-dnsext-trustupdate-timers-04
>           Automated Updates of DNSSEC Trust Anchors
>
> The documents and their history can be found at:
>
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rollover- 
> requirements/
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-timers/
>
>
> It is the intention to publish the "requirements" draft as an
> informational RFC and to publish "timers" on standards track.
>
> As previously, for each document we would like to see at least 5  
> people
> going on record for having thoroughly reviewed it.
>
> We would appreciate assessments on how well 'timers' fits  
> 'requirements' [*]
>
>
> Last call terminates October 11, 2006.
>
>
> Your chairs,
>
> Olaf and Olafur.
>
>
> [*] Even though there is no reference from the timers draft to the
> requirements draft we learned by experience with that the IESG is
> interested and aware of requirement documents and takes interest
> reviewing them both.
>
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
>
>
>

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 09 Oct 2006 14:48:48 +0200

Hi,

I've already reviewed -timers, and agree with moving it forwards (please
address the concerns I raised).

I've just reviewed the rollover-requirements-03 and I find it acceptable.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Oct 2006 08:29:20 -0500

>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rollover-requirements/

>As previously, for each document we would like to see at least 5 people

I haven't had time to look at these documents in their recent state.

The reason I haven't - and am bothering to say so - is that it is a 
matter of priorities.  I do think that solving this is worthwhile and 
that the documents would merit review, but I find the task of 
reviewing them deep in my job queue.

Not speaking for my employer (who is an TLD operator) but recognizing 
that it is a major player in my setting of priorities, there are a 
few reasons why this review task remains deep in my queue.

One is that there are plenty of other things to work on these days. 
I'm reviewing documents in other IETF groups that have more urgency. 
Another is that I have been disappointed that the TLDs are currently 
in the position of "should be concerned" about this topic.

I am disheartened in the lack of visible progress in the signing of 
the root zone and other infrastructure zones.  Although I rub elbows 
quite often with people that are intimately involved in the effort to 
accomplish signing the root and they drop hints that "it is coming" 
"in 6 months" I have not seen any evidence that it really is going 
forward.  (I don't consider slide-ware evidence.)

Perhaps there is a deadly embrace here - maybe until these documents 
go forward, DNSSEC is stuck in the root zone.  But I haven't heard 
that as an enticement.

I would be willing to review these documents, but time constraints 
are in place because of work I find more fruitful at this time. 
Keeping in mind that the IETF is a volunteer effort, I think a 
"tastier carrot" would be nice, like real and evident progress on 
getting the root zone (and the other infrastructure zones like arpa 
and in-addr.arpa) signed.

Has the IAB set out a calendar for the deployment of DNSSEC in the 
zones they control?  Seeing a formal statement from within (the IETF) 
would be nice.

>Last call terminates October 11, 2006.

I don't mean to say that DNSSEC is petering out.  An increasing 
number of status slides at RIPE show interest in it in various 
registries.  But there is a lot of other work to do these days.

It's a matter of time and priorities.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Oct 2006 11:59:13 -0400

Ed,

On Oct 10, 2006, at 9:29 AM, Edward Lewis wrote:
> the root zone and other infrastructure zones.

I won't comment on the root, but as for infrastructure zones, at the  
request of the IAB IANA has committed to  
signing .ARPA, .URN.ARPA, .URI.ARPA, IRIS.ARPA and hopefully IP6.ARPA  
by the end of the year.

Rgds,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Oct 2006 11:36:57 -0500

At 11:59 -0400 10/10/06, David Conrad wrote:

>I won't comment on the root, but as for infrastructure zones, at the request
>of the IAB IANA has committed to signing .ARPA, .URN.ARPA, .URI.ARPA,
>IRIS.ARPA and hopefully IP6.ARPA by the end of the year.

Cool - then we'll have a place to see a real DS set exchange (i.e., 
at least between RIPE and IANA in IPv6 reverse zones like 2a01::).

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Oct 2006 12:44:39 -0400

Colleagues,

I have read the documents above.  I believe that
draft-ietf-dnsext-rollover-requirements-03 captures the set of
requirements strictly necessary for key rollover (although note a
comment about number 8, below).  I acknowlege Thierry Moreau's
argument that a wider set of operational procedures might also be
necessary for at least some contexts, but I suggest that the wider
set is partly a set of practices better outlined as in an operational
advice.  So I support this document going forward.

Here is my evaluation of the extent to which
draft-ietf-dnsext-trustupdate-timers-04 meets the requirements above. 
On the basis of my evaluation, I support the document proceeding:

1.	Scalability: within the limits outlined in -requirements-03,
yes.

2.	No IPR Encumbrance: maybe.  At the last IETF meeting, I
recall someone mentioning that the IPR claim that is outstanding is
not valid.  The IETF IPR pages do not reflect that view, however, so
I can't tell.

3.	General Applicability: yes.

4.	Private Networks: yes.

5.	Detection of Stale Anchors: yes.

6.	Manual Operation: sort of.  The document requires the passage
of time for certain operations, and that passage of time cannot be
performed "manually" (barring some change in the metaphysical realm
of which I'm unaware.  I know there are some pretty good engineers
here, but I'm fairly sure that problem hasn't been solved).

7.	Planned and Unplanned Rollovers: yes.

8.	Timeliness: To the extent I understand this requirement, yes.
It seems a slightly vague requirement, in that there's no definition
of what a timely manner is.  The -timers-04 draft sets minimum times
in most cases at 30 days, which seems reasonable to me.  It would be
nice for that time line to be something that is determined by policy
published in the DNS itself, and if we had a policy RR of some sort,
I'd strongly support putting this time in there instead.  (I can
think of cases where 30 days sounds like an awful lot, so it makes me
nervous.)

9.	High Availability: yes.  

10.	New RR Types: this requirement has been expanded from earlier
drafts to include any protocol changes.  The -timers-04 draft does
require a minor modification, but I think this is perhaps a good
thing.

11.	Trust Anchor Maintenance Operations: yes. 

12.	Recovery From Compromise: yes.  Note that in the case of
two-key compromise on a zone with two configured keys, it seems to me
that the outline in section 2.2 of -timers-04 is extremely important,
because the add hold down period does not completely block the
attack.  I think this probably needs to be emphasised a little more
in the Security Considerations section, because it seems to me to be
the weakest point in the proposal.  I suggest an addition in section
8.2:

   The zone owner should determine their own level of comfort with
   respect to the number of active valid trust anchors in a zone and
   should be prepared to implement recovery procedures once they
   detect a compromise.  In assessing the number of active valid
   anchors, a zone owner should be sure to consider the consequences
   of key compromise and the way it motivates the Add Hold-down
   period (section 2.2).

13.	Non-degrading Trust: yes

Best regards,
A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: char sample <[email-masked]>
Date: Tue, 10 Oct 2006 11:08:05 -0700 (PDT)

I have completed the review of the rollover-requirements document and I am OK w/ the contents of that document as it currently reads. 

I am reviewing the timers one and hope to have that one completed later today.

char sample
Sparta, Inc.

"Olaf M. Kolkman" <[email-masked]> wrote: 

Colleagues,

--Olaf

(Top-Posting)

 		
---------------------------------
Stay in the know. Pulse on the new Yahoo.com.  Check it out.

---

From: char sample <[email-masked]>
Date: Tue, 10 Oct 2006 13:43:24 -0700 (PDT)

I have completed the draft on the times and am OK w/ this one too.  I recommend both drafts move forward to the next step in the process.

char sample
Sparta Inc.

Colleagues,

--Olaf

(Top-Posting)

 			
---------------------------------
Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Tue, 10 Oct 2006 18:47:05 -0400

I've already indicated my support for the "timers" approach in the  
past. I've re-read draft-ietf-dnsext-trustupdate-timers-04 and  
support it going forward.

Suresh

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 11 Oct 2006 11:25:25 +0200

On 10Oct 2006, at 3:29 PM, Edward Lewis wrote:

> zones they control?  Seeing a formal statement from within (the  
> IETF) would be nice.
>

See:
http://www.iab.org/documents/correspondence/2006-05-15-IAB-request-to- 
IANA-to-sign-DNSSEC-zones.html

Last week John Crain reported: ".int and .arpa signed by the end of   
year" (slide 5 of http://www.ripe.net/ripe/meetings/ripe-53/ 
presentations/icann_dns_wg.pdf)

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 11 Oct 2006 11:45:23 +0200

On 9Oct 2006, at 2:35 PM, Olaf M. Kolkman wrote:

>
>
> Colleagues,
>
> This is a reminder. The WGLC closes in about 2 days; we have not  
> met quorum yet.
>
> let us know. I'd hate if we would need to declare bankruptcy at  
> this stage because of lack of review by the working group.

Some people indicated they need a bit more time. I think we met  
quorum but I would still like to see the responses and take them into  
account.

I will review last call sometime next week, probably at the end of it.

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Oct 2006 12:31:24 +0000

> Last week John Crain reported: ".int and .arpa signed by the end of   year"
> (slide 5 of http://www.ripe.net/ripe/meetings/ripe-53/

.arpa is a good start but what about in-addr.arpa?

---

From: Mike StJohns <[email-masked]>
Date: Wed, 11 Oct 2006 08:42:26 -0400

I know you'd like to wait, but let's close this by Friday 
please.  I've got to do one more pass to change two items - fix 
spelling and clarify how to calculate the minimum retransmit time - 
and I'd like to do that this weekend so I can resubmit in plenty of 
time for the deadline.  These changes are editorial only and don't 
change the meaning of the document.

Mike

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 11 Oct 2006 19:32:33 +0200

On 11Oct 2006, at 2:42 PM, Mike StJohns wrote:

> I know you'd like to wait, but let's close this by Friday please.   
> I've got to do one more pass to change two items - fix spelling and  
> clarify how to calculate the minimum retransmit time - and I'd like  
> to do that this weekend so I can resubmit in plenty of time for the  
> deadline.  These changes are editorial only and don't change the  
> meaning of the document.
>

Fair enough...

But I have commitments that will not allow me to do the summary this  
week.

I propose the following:

Friday 9 am EST is the last moment that the working group can submit  
feedback on your document. You use that to rev the draft and publish  
it.  Once you've published the draft you notify the working group so  
they can double check the last rev.

Assuming that there is no change in the current trend there will be  
consensus to forward and I'll try to do the proto statement in the  
next two weeks and push this towards IESG.

--Olaf

---

From: Mike StJohns <[email-masked]>
Date: Wed, 11 Oct 2006 18:12:51 -0400

Works for me.  Thanks! Mike

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 11 Oct 2006 22:45:29 -0400

Dear all:

As the TAK rollover WGLC nears completion within the DNSEXT wg, I 
attempt to summarize my views on this activity. I include in a single 
message a critique on the TAK management requirements document 
(draft-ietf-dnsext-rollover-requirements-03.txt) and the IETF expected 
solution for automated TAK rollover 
(draft-ietf-dnsext-trustupdate-timers-04.txt).

There are no new arguments in the present message, nor an attempt to 
change other participants' opinions. It's just a summary.

LACK OF A SECURITY MODEL FOR AUTOMATED TRUST ANCHOR ROLLOVER

Although DNSSEC is an IT security protocol, when it came to an automated 
TAK rollover protocol, the DNSEXT wg omits a documented security model 
as a side issue. For trustupdate-timers, this has been raised by Eric 
Rescorla in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01026.html , 
and then replied in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01035.html 
and http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01037.html .

Incidentally, it is almost by accident that the rollover-requirements 
paragraph 5.13. (Non-degrading trust) remains in the current draft 
(compare 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00624.html 
and 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00695.html 
). Moreover, an expert review of the TAK rollover alternatives found the 
requirement ill-defined: "May be a policy issue (which algorithm to 
allow etc). How does one define degraded trustworthiness?" (from at 
http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm brought 
to the DNSEXT wg attention in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00862.html 
). This does not prevent this same expert from supporting the IETF 
expected solution for automated TAK rollover 
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01311.html).

At one point, I argued that the actual scope of rollover-requirements 
was too broad ("trust anchor management"), and should instead focus on 
the automated trust anchor rollover operation, perhaps even more 
narrowly on rollover *within the DNS protocol* ( 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00630.html 
). Indeed, the only use of rollover-requirements is the selection of an 
automated TAK rollover solution. In progressing a high level "trust 
anchor management" requirements document, the DNSEXT wg stayed away from 
a reasonable statement for a security model for automated trust anchor 
rollover.

The lack of a security model is perhaps coherent with the limited 
operational guidelines found in trustupdate-timers. This seems to shift 
some of the work to DNSOP, and/or to DNS zone administrations that 
cannot avoid the island-of-trust status (e.g. ICANN as the DNS root zone 
administration). However, an IT security scheme is strengthened when the 
various aspects (e.g. technological, parameter selection, 
implementation, operations) are considered at once in a single security 
analysis.

WG PROCESS OF INTELLECTUAL PROPERTY ISSUE

IPR encumbrance has been discussed at length in the DNSEXT wg mailing 
list. The draft-ietf-dnsext-rollover-requirements-03.txt document, in 
its paragraph 5.2, varies the IPR-related process defined in RFC 3668. 
In one message, I argued that the working group used an "a-priori option 
abandonment formulation" in this paragraph 5.2, committing itself to 
reject one of the solution, without a reasonable justification ( 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00239.html 
). Despite mitigating observations by DNSEXT chairman and minor 
rewording in the -02 draft revision, the paragraph 5.2 was quite 
effective as an a-priori option abandonment.

The adoption of draft-ietf-dnsext-rollover-requirements-03.txt as an 
informational RFC may establish a precedent in wg process for the 
selection of a technology, shifting the balance towards an ideological 
avoidance of IPR encumbered solutions. Perhaps the IESG wishes to keep 
RFC 3668 as the sole authoritative text on these matters.

CONCLUSION

I object to the progress of draft-ietf-dnsext-rollover-requirements-03.txt.

Since draft-ietf-dnsext-rollover-requirements-03.txt is likely to be 
adopted, I abstain about draft-ietf-dnsext-trustupdate-timers-04.txt 
(i.e. the lack of a security model in rollover-requirements makes 
trustupdate-timers a "good enough" solution).

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Sam Weiler <[email-masked]>
Date: Thu, 12 Oct 2006 15:40:56 -0400 (EDT)

First, my appreciation to MSJ for the excellent editting job.

I found a couple of minor things in the doc that I'd like to see 
clarified.  While it would be better to do that before sending the doc 
to the IESG, my only objection to advancing the doc now is the 
discrepancy in section 2.3 identified by Wouter and Lindy.  In 
particular, the second sentence of 2.3 seems inconsistent with the 
rest of the doc.

I'll start with the disucssion of how I think this technique stacks up
against the requirements (identified by the section number in the
requirements draft), then I'll list the textual clarifications I'd
like to see.

I think this doc satisfies these requirements:
      5.1.  Scalability
      5.3.  General Applicability
      5.4.  Support Private Networks
      5.7.  Planned and Unplanned Rollovers
      5.8.  Timeliness
      5.10. New RR Types (unclear requirement, but no new RR type needed)
      5.11. Support for Trust Anchor Maintenance Operations
            (accomplishes replace w/ separate add/delete)
      5.12. Recovery From Compromise
      5.13. Non-degrading Trust

I think both of the following are satisfied, though more text about
them would be good:
      5.5.  Detection of Stale Trust Anchors
      5.6.  Manual Operations Permitted

I'm concerned that limits on the size of the apex DNSKEYset will
prevent keeping around a sufficient number of revoked DNSKEYs to fully
satisfy:
      5.9.  High Availability
            (but I don't think we need to do anything about this now)

I make no comment on this requirement:
      5.2.  No Intellectual Property Encumbrance

Clarifications:

2535 is listed as a normative reference, but it's obsolete.  Remove it
entirely?

--

As above, considering adding more text re: how to satisfy requirements
5.5 and 5.6.  That said, if it weren't for reading both this doc and
the requirements doc in one sitting, I wouldn't think this document
needed such text.

--

Section 6: "The stand-by key will not normally sign this RRSet, but
the resolver will accept it as a trust anchor if/when it sees the
signature on the trust point DNSKEY RRSet."

Which signature?  It's own?  The "NewKey" event description makes it
sound like just adding the SEP key to the signed DNSKEYset is enough
to get resolvers to pick it up.  Once it's picked up, it could even be
used to sign data in the zone (used as a ZSK) even without
self-signing the DNSKEYset, right?

How about: "Even though the stand-by key will not normally sign this
RRSet nor any other data in the zone, but the resolver will accept it
as a trust anchor.  Accordingly, it could be used to sign the DNSKEY
RRset or any other zone data." ?

--

The phrase "SEP key" is used, with a reference to 4034, but 4034
doesn't define "SEP key".  It would be more correct, and perhaps less
confusing, to say "a DNSKEY with the SEP bit set".  Make that
substitution globally.

--

In the "Valid" state: "If the RRSet ..."  Which RRset?  How about "If
a DNSKEY RRset..."  Yes, it's slightly redundant.

--

   "Alternately, a trust point which is subordinate to another
    configured trust point MAY be deleted by a resolver after 180 days
    where such trust point validly chains to a superior trust point.
    The decision to delete the subordinate trust anchor is a local
    configuration decision.  Once the subordinate trust point is
    deleted, validation of the subordinate zone is dependent on
    validating the chain of trust to the superior trust point."

The word "to" in the above assumes a "bottom-up" logical model of
validation, which is not the one I'm most familiar with seeing in
writing.  Perhaps a change is in order?

--

The abstract says "the method provides protection against single key
compromise", but 8.2 says "This scheme permits recovery as long as at
least one valid trust anchor key remains uncompromised."  While these
aren't necessarily contradictory, they come close.

--

Section 1: "a resolver may need to know literally thousands of trust
anchors to perform its duties." is inconsistent with the requirements
doc: "never expected to be as high as one thousand."  I prefer this
version; change the other doc.

--

Section 8.1: "This implies the decision update trust anchor keys based
on trust for a current trust anchor key is also the resolver owner's
decision."

There's something missing in that sentence.

--

The doc still flags as a "discussion item": "Should a missing key be
considered revoked after some period of time?"  Might want to remove
that before sending it to the IESG.

---

From: Mike StJohns <[email-masked]>
Date: Sat, 21 Oct 2006 21:56:54 -0400

At 03:40 PM 10/12/2006, Sam Weiler wrote:
>clarified.  While it would be better to do that before sending the 
>doc to the IESG, my only objection to advancing the doc now is the 

There is no discrepancy... please once again review both the text and 
my response.

>2535 is listed as a normative reference, but it's obsolete.  Remove it

Hmm... I think there was a reason it was included - I'll review the 
bidding and remove it if necessary otherwise  I'll report back here.

Nope.

>Which signature?  It's own?

Yup.  Should be obvious by context.

>  The "NewKey" event description makes it
>to get resolvers to pick it up.

  NewKey  The resolver sees a valid DNSKEY RRSet with a new SEP key.
       That key will become a new trust anchor for the named trust point
       after its been present in the RRSet for at least 'add time'.

Not really.
>Once it's picked up, it could even be

Yes, but it can't get there first without signing the DNSKEY RRSet - 
not part of this protocol to describe all the ways zone operators can 
screw up, just to describe what the resolver does when it sees it.  No change.

>RRset or any other zone data." ?

I'm not going to make this change on a WGLC document.  I would 
probably have done this if it had been suggested any time prior to 
the -04 draft.  It's in the informational section and would require 
more than just simple editorial changes.

Nope - but I will add it as a parenthetical introduction (e.g. DNSKEY 
with the SEP bit set) once.

Nope.

Nope.  Either "to" or "from" would work here - but neither should 
imply an implementation strategy which appears to be what you're referencing.

Fair.

Sure, no change here.

"to update" - will add the "to"

Yup.